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I n t egr i e r t e s Da t enbank - Ver bundsy s t em 



Die Erfindung bezieht sich auf die Integration unter- 
schiedlicher strukturell inkompatibler Datenbanksysteme . 

Datenbanksysteme spielen in zahlreichen Anwendungen der 
elektronischen Datenverarbeitung eine groSe Rolle. Sie 
bestehen ublicherweise aus der eigentlichen Datenbank 
(Datenbasis) und einem Da tenbankmanagement system. Oft 
sind sie Grundlage umf as sender Compute rapplikationen, bei 
denen die in der Datenbank gespeicherten Daten in vielfa- 
cher Weise weiterverarbeitet werden. 

Ein wichtiges Beispiel im Bereich der Unternehmens-EDV 
sind sogenannte ERP (Enterprise Resource Planning) -Sy- 
steme, wie beispielsweise OLTP-R/3 der SAP AG, Walldorf , 
Deutschland. Sie ermoglichen die EDV-Unterstutzung unter- 
schiedlichster Unternehmensbereiche, wie beispielsweise 
Personal, Vertrieb, Lagerhaltung etc. auf Basis einer 
gemeinsamen zentralen Datenbank. Derartige Systeme werden 
vielfach als "Back-off ice-System" bezeichnet. 

Ein we i teres wichtiges Beispiel von Datenbanksystemen 
sind Kundenbetreuungs systeme , die vielfach als SFA (Sales 
Force Automation)- oder CRM (Customer Relation Manage- 
ment) -Systeme bezeichnet werden. Derartige Systeme sind 
besonders auf die EDV-Anf orderungen der Kundenberatung , 
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Kundenbetreuung und des Vertriebs zugeschnitten. Hierzu 
gehort, dafi die Moglichkeit besteht, AuSendienstmitarbei- 
ter des Unternehmens mit einem tragbaren Rechner auszuru- 
sten, der als sogenannter mobiler Klient (mobile client) 
des Datenbanksysteras eine eigene lokale Datenbank mit dem 
von dem jeweiligen Aufiendi ens tmitarbe iter bendtigten 
Daten (beispielsweise uber die Kunden aus seinem Bezirk 
oder den Status der von ihm getatigten Verkaufe) zur Ver- 
fugung stellt . Zu einem solchen System (das vielfach als 
Front-Off ice -System bezeichnet wird) gehort ein Zentral- 
rechner, der ebenfalls eine Datenbank enthalt, in der die 
Summe der Daten "der mobilen Klienten gespeichert ist . Es 
handelt sich also urn ein of f line-verteiltes Datenbank - 
system. Neben den mobilen Klienten konnen mit dem Zen- 
tral rechner des CRM-Systems ^auch andere externe Systeme 
kommunizierenr, wie -beispre;l*sweise EDV-Syst'eme^von Kunden, 
die uber/„temporare -oder stationare- Datenverb'indungen an 
den Zentralrechner angeschlossen v sind. 

Sowohl gebrauchliche Back-off ice -Systeme als auch ge- 
brauchliche Front-off ice -Systeme sind auJSerordentlich 
komplex. Sie erfordern jeweils leistungsf ahige Methoden 
zur Sicherstellung der Kommunikationsf ahigkeit zwischen 
den verschiedenen Komponenten der Datenintegritat und der 
Da t ensynchr oni s a t i on , wobei zu berucksichtigen ist, daiS 
die Kommunikation sehr groEe Benutzerzahlen einschliefien 
kann. 

Wahrend diese Prob 1 erne fur umfangreiche Systeme der ge- 
nannten Art weitgehend . gelost sind, fehlt es noch an 
uberzeugenden Verfahren, Datenbanksysteme miteinander zu 
verschmelzen, die strukturell inkompatibel sind, aber zu 
einem erheblichen Teil die gleichen (Geschaf ts- ) Daten 
verwalten. Beispielsweise sind in ERP-Systemen normaler- 
weise umfangreiche Datenbestande uber die Kunden des 



: ^-^-'Sf y-x;' w: :.^k k^: >k# m> 




Unternehmens (z.B. Adressen, Ansprechpartner, Daten uber 
erledigte Auftrage, Einkauf skonditionen, aber auch die 
fur Ersatzteilbelieferung wichtige Maschinenausstattung 
der Kunden) gespeichert. Weitgehend ubereinstimmende Da- 
tenbestande we r den auch in CRM-Systemen bendtigt. In der 
Praxis haben beide Systeme jedoch eine ganz unterschied- 
liche wechselseitig inkompatible Datenbankstruktur . 

Beispielsweise ist die Pre isermitt lung (prizing) eine 
Aufgabe, die in unterschiedlichen Applikationen EDV-un- 
terstutzt durchgefuhrt wird. Obwohl ein einheitlicher ge- 
schaf tlicher Ablauf (beispielsweise unter Berucksichti- 
gung der Gestehungskosten, der Stuckzahl, der Transport- 
kosten und eventueller Sonde rkonditionen) zugrundeliegt , 
ist die Implement ierung in unterschiedlichen Datenbank- 
systemen haufig vollig verschieden, d.h. die Algorithmen 
(sogenannte "Businesslogik" ) , die zur Umsetzung der ge- 
schaft lichen Vorgange benutzt werden, sind sehr verschie- 
den. Selbstverstandlich besteht jedoch das Bedurfnis, daS 
eine Pre isermitt lung in unterschiedlichen Systemen mog- 
lichst gehandhabt werden kann und zu dem gleichen Ergeb- 
nis f uhrt . 

Die Erfindung befaSt sich mit dem Problem, derartige 
strukturell inkompatible Datenbanksysteme derartig mit- 
einander zu verschmelzen, dafi ein problemloser Datenaus- 
tausch in beide Richtungen moglich ist. "Verschmelzen" 
von Systemen ist dabei in dem Sinn zu verstehen, daS - 
uber die technische Anbindung hinaus - die Datensynchro- 
nisation und ein derartiger Austausch der Steuerungslogik 
moglich ist, daS ein annahernd gleiches Verhalten der 
verschiedenen Systeme erreicht wird. Ein derartiges Ver- 
schmelzen zu einem aus mehreren Teil systemen bestehenden 
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integrierten Verbundsystem wird hier auch als "semanti- 
sche Systemintegration" bezeichnet. Sie erfordert unter 
anderem : 

- eine gesicherte technische Anbindung der Systeme, 

die Synchronisation der Nut 2 da ten der verschmolzenen 
Systeme, 

die Synchronisation der kundenspezif ischen Anpassung 
(Customizing-Daten) zur Steuerung der verschmolzenen 
Systeme, 

- geeignete Konf likt-Auf losungsverf ahren im Falle diver- 
gierender Datenanderungen oder anderer Daten-Inkonsi- 
stenzen. 

Zur Her^stellung ( einer stabilen Verbindung sowohl online 
als auch of f linens tehen bewahrte ^H^rd- und*?So£»tware-Tech- 
niken zur Verf u§ung.i; Eine^wesentliche**Rcfarle -"spiel en dabei 
Queueing-Mechanismen; die ^sicherstellen, da£ jede Daten- 
einheit genau e initial- ubertragen^ wi-rd (guaranteed deli- 
very) und die Daten in einer exakt festgelegten Reihen- 
folge ubertragen werden (In-Order-Processing) . Dieser 
Teilaspekt der semant ischen Systemintegration mufi nicht 
naher erlautert werden. 

Dagegen stellt die Erfullung der anderen genannten Erfor- 
dernisse ein sehr schwieriges Problem dar, zumal in der 
Regel davon auszugehen ist, dafi unterschiedl-iche Daten- 
banksysteme unterschiedlichen "Wei ten" von Software- Pro - 
dukt en angehor en- konnen . Der Erf indung**! i egt? f di e Auf gabe 
zugrunde, Systemkomponenten und^Veisf ahren- zur;.L6sung die- 
ser Probleme zur Verfugung zu stellen. 

Die Datenmodelle verschiedener Datenbanksysteme sind un- 
terschiedlich. Deshalb mussen ihre Datenstrukturen auf- 
einander gemappt werden. AuJSerdem ist eine entsprechende 
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Anpassung der Dateninhalte (z.B. Begriffswahl "Kunde" in 
einem System entspricht "Abnehmer" in einem anderen Sy- 
stem) erf orderlich. Diese beiden Funktionen sind Stan- 
dardaufgabenstellungen beim Datenaustausch zwischen zwei 
nichtkompatiblen Systemen. Herkommliche Systemverbindun- 
gen beschranken sich auf diese Art der Anbindung. Hieraus 
ergibt sich, dafi Neuerf assungen von Da ten, die in dem ge- 
samten Verbundsystem wirksam sein sollen, nur in einem 
der Systeme, das als zentrales System bezeichnet wird, 
mit Wirkung fur das gesamte Datenbankverbundsystem durch - 
gefuhrt werden konnen. Dies ist aber in manchen Fallen, 
beispielsweise bei der Verschmelzung eines CRM-Systems 
mit einem ERP-System, nicht ausreichend, weil hier we- 
sentliche neue Da ten sowohl im Hauptquartier des Unter- 
nehmens (also dem ERP- System) als auch im Rahmen der Kun- 
denbetreuung (also in dem CRM-System) anfallen und nach 
der Neuaufnahme in dem gesamten Verbundsystem verfugbar 
sein sollen. 

Wenn es mdglich sein soil, Neuerf assungen von Daten, die 
systemubergreifend geshart werden (also nach Durchfuhrung 
der Neuerf assung in alien Teil systemen des Verbundsys terns 
zur Verfugung stehen) , in jedem Teilsystem des Verbund- 
systems durchzufuhren, bedingt dies, da£ jederzeit sy- 
stemubergreifend ein eindeutiger Primarschlussel zur 
I dent if ikation der Datenobjekte zur Verfugung stehen. 
Bekannt ist es, derartige Primarschlussel durch Vergabe 
von Nummernkreisen oder durch Vergabe von GUID (Global 
Unified Identifier) -Schlusseln zu erzeugen. Beide Verfah- 
ren sind jedoch nicht universell anwendbar. 

Die Nummernkreisvergabe bedingt gleiche Algorithmen zur 
Schlusselgenerierung in den beteiligten Datenbanksyste- 
men. Dies kann bei Systemen unterschiedlicher Hersteller 
nicht gewahrleistet werden. Auch in unterschiedlichen 



Systemen des gleichen Herstellers sind hauf ig unter- 
schiedliche Schlusselgenerierungsverf ahren implement iert . 

Die Erzeugung eines eindeutigen Schlussels rait Hilfe von 
GUIDs ist nur anwendbar, wenn alle beteiligten Systeme 
das GUID-Verf ahren nutzen. Auch dies kann in vielen Fal- 
len nicht gewahrleistet werden. 

GemaB einem ersten Aspekt der Erf indung wird zur Losung 
des daraus resultierenden Problems ein Verf ahren zurn Aus- 
tausch von Daten zwischen zwei Datenbanksystemen A und B, 
wobei jedes der Datenbanksysteme zur eindeutigen Identi- 
fizierung gespei cheater Datemobjekte fur jedes* Da tenob- 
jekt mi*ttel*s einei&rPrdmarsGhlussel-Erzeugungslogik einen 
sy s fcemsge z i f d schen Pr imar.schl-us s .eiK gener i er,fe* und** di e Pr i - 
mar s chluslselr- Easzeugungs J-ogiken deTr^be.i den w Da£enbaiiksy s t e - 
me*A *und MB #vonei*nande*^ ^unabhaSgdjg -* s indole vo-rges chl agen , 
bei welchem zur ~E2?m6glichung der f ur^systemubergreif end 
gesharte Neuerf assun^en - nofewendigen- eindeutigen I dent if i - 
zierbarkeit von aus einem Ursprungsdatenbanksystem A in 
ein Zieldatenbanksystem B transport iert en Datenobjekten 
folgende Schritte durchgefuhrt werden: 

a) Der Primarschlussel von Datenobjekten, die von dem 
Ursprungsdatenbanksystem A in das Zieldatenbanksystem 
B transport iert werden soil, werden mitt els eines Pri- 
marschlusselgenerators mit einer Schlussel-Mapping-Ta- 
belle verg lichen", die die Primasssohlusse-1* aller Daten- 
objekte, fur die bereits beide Primarschlussel gene- 
rrert wu-rden^ entehalt ; 

b) werirf dei^ Primarseh>lussel in dear-* S chl us sei- Mapping -Ta- 
belle noch nicht vorhanden ist, wird automatisch ein 
Primarschlussel _ des Zieldatenbank systems B erzeugt, ii 
dem Datenobjekt gespeichert und zusammen mit dem 
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Primarschlussel des Ursprungsdatenbanksys terns A in der 
Schlussel-Mapping-Tabelle KMT abgelegt. 

c) wenn der Primarschlussel des Ursprungsdatenbanksys terns 
A in der Schlussel-Mapping-Tabelle gefunden wurde, 
wird der entsprechende Primarschlussel des Zieldaten- 
banksystems B in dem Datenobjekt gespeichert . 

Dadurch ist die Erzeugung eines systemubergreif end ein- 
deutigen Primarschlussel s (und damit die Durchfuhrung von 
systemubergreif end gesharten Neuerf assungen) auch in Fal- 
len moglich, bei denen jedes beteiligte Datenbanksystem 
seine eigene Primarschlussel -Erzeugungslogik verwendet 
und diese Logiken nicht aufeinander abgestimmt sind. Man 
definiert die Schlussellogiken im Steuerdaten-Speicher 
(Repository) der beteiligten Systeme . Mittels des Schlus- 
selgenerators werden die beiden Logiken aufeinander abge- 
bildet . 

Gemafi einem zweiten Aspekt richtet sich die Erfindung auf 
ein Verfahren zum Updaten des Datenbestandes in einem 
zweiten Datenbanksystem B aufgrund von Anderungen, die in 
einem ersten Datenbanksystem A im dortigen Datenbestand 
durchgefuhrt wurden, wobei der Datenbestand des ersten 
Datenbanksystem A sowohl fur das zweite Da tenbanksys terns 
B nicht relevante Daten als auch fur das zweite Daten- 
banksystem A relevante Daten enthalt, die Daten in den 
Datenbanksystemen in Form von Datenobj ekten bearbeitet 
werden, die jeweils einen systemspezif ischen Primar- 
schlussel enthalten, und die Daten in dem zweiten Daten- 
banksystems B mit beiden systemspezif ischen Primarschlus- 
seln gespeichert werden, bei welchem mindestens ein Teil 
folgender Verf ahrensschritte durchgefuhrt wird: 

a) Abtrennen der fur das zweite Da tenbanksys terns B nicht 
relevanten Daten D R y 3 aus dem Datenobjekt; 
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b) Ubertritt des Datenobjektes von dem erst en Datenbank- 
system- A in das zweite Datenbanksystem B; 

c) Erzeugen eines fur das Datenbanksystem B spezifischen 
Schlussel und Hinzufugen des erzeugten Schlussels zu 
dem Datenobjekt und 

d) Einbringen des entstandenen Datenobjektes in die Ab- 
speicherungsroutine des zweiten Datenbanksys terns B und 
Abspeichern der in dem Datenobjekt enthaltenen Daten 
in der Datenbank des zweite Datenbanksystem B. 

Bevorzugt werden alle Schritte a) bis d) durchgef uhrt . 

Gemafi einem we&teren Aspekt richtefe, sich die Erfindung 
auf ein Verf ahren zum -Updat en, -de St* ;Da*tenbes tandes in einem 
ersten'-Dafcenbanksyst3'em-*A ^auf.g^und^von-^Anderungenf, die in 
einem^zweiten^Dat^enbanks^sfeem B "im addrtigen C^fcenbestand 
durchgef Onrt iwu-rden, wobea* der Dafeenbestand des zweiten 
Datenbank systems B sowohl- fur das-erste Datenbanksystem A 
nicht relevante Daten als auch fur das erste Datenbanksy- 
stem A relevante Daten enthalt, die Daten in den Daten - 
banksystemen in Form von Datenob j ekten bearbeitet werden, 
die jewells einen systemspezif ischen Primarschlussel ent- 
halten, und die Daten in dem ersten Datenbanksystem A nur 
mit dessen systemspezif ischem Primarschlussel gespeichert 
werden / bei welchem mindestens ein Teil folgender Verfah- 
rensschritte durchgef uhrt wird: 

a) Abtrennen der fur das erste Datenbanksystem. A nicht 
relevant en Daten D MS aus dem Datenob jektsmnd Parken 
dieser Daben in dem zweiten Datenbanksystem*©; 

b) Ubertritt des Datenobjektes von dem zweiten Datenbank- 
system B in das erste Datenbanksystem A; 

c) Abtrennen des fur das zweite Datenbanksystem B sy- 
stemspezif ischen Schlussels aus dem Datenobjekt und 
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Parken dieses Schlussels in dem ersten Datenbanksystem 



d) Einbringen des entstandenen Datenobjektes in die Ab- 
speicherungsroutine des ersten Da tenbanksys terns A und 
Abspeichern der in dem Datenobjekt enthaltenen Daten 
in der Datenbank des ersten Datenbankssystems A. 

Bevorzugt werden alle Schritte a) bis d) durchgef uhrt . 

GemaS noch einem weiteren Aspekt der Erfindung wird ein 
Verfahren zur Neuerfassung oder Anderung von Daten in ei- 
nem Verbund mehrerer Datenbanksysteme vorgeschlagen, bei 
welchem zur Vermeidung von Datenkonf likten. bei der ge- 
sharten Neuerfassung von Daten in einem beliebigen der 
Datenbanksysteme des Verbundes fur jedes zwischen den Da- 
tenbanksystemen austauschbare Datenobjekt eines der Da- 
tenbanksysteme als f uhxendes System FS definiert wird und 
bei jeder Neuerfassung oder Anderung in einem gefuhrten 
Systems GS von Daten des Datenobj ekts , die auch zum Da- 
tenbestand des fuhrenden Systems FS gehoren, ein system- 
ubergreif ender Bestatigungsalgorithmus durchgefuhrt wird, 
bei dem 

a) ein Datenobjekt, das die Anderung beinhaltet, zu dem 
fuhrenden System FS transport iert wird, 

b) in dem fuhrenden System FS eine Ruckmeldung in Form 
einer Bestatigung oder mindestens teilweisen Ablehnung 
der Anderung erzeugt wird und 

c) ein Datenobjekt, das die Ruckmeldung enthalt, zu dem 
gefuhrten System GS zurucktransportiert wird. 



A; 



Die Erfindung wird nachfolgend anhand von in den Figuren 
dargestellten Ausfuhrungsbei spiel en naher erlautert. Die 
darin beschriebenen Besonderheiten konnen einzeln oder in 
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Kombination miteinander eingesetzt werden, urn bevorzugte 
Ausgestaltungen der Erfindung zu schaffen. Es zeigen: 

Fig. 1 einen Uberblick uber das Umfeld eines erfin- 

dungsgemaSen Verbundsys terns of f line-verteilter 
Da t enbanken , 

Fig. 2 einen Uberblick uber die Architektur eines im 
Rahmen der Erfindung verwendeten Front-off ice- 
Systems am Beispiel eines CRM- Systems , 

Fig. 3 einen typischen Ablauf der FluiSsteuerung des 
Systems nach Figur 2 am Beispiel eines Daten- 
Upload-Vorgangs , 

Fig. 4 die Struktur von in dem System nach Figur 2 
verwendeten Datenobj ekten _ ( " BDbcs " ) , 

Fig/ 5 die Architektur der in-zwei gema£~der, Erf indung 
miteinander verbundenen bei dem^Upload und 
De It adownl oad^von - Dat en wi r ks amen Kompbnent en , 

Fig. 6 ein Ablauf diagramm entsprechend Figur 3 fur den 
Fall eines De It adownl oad, 

Fig. 7 die Architektur der fur die Erstdatenbef ullung 
eines der beteiligten Datenbanksysteme mit in 
dem anderen Datenbanksystem enthaltenen Daten 
verwendeten Komponenten, 

Fig. 8 eine Prinzipdarstellung zur Erlauterung eines 

Verfahrens zur systemubergreif enden Bereitstel- 
lung der erf orderlichen Primarschlussel , 

Fig. 9 ein Beispiel fur die Segmentstruktur eines BDoc 
und der zugehdrigen Schlussel-Mapping-Tabelle, 

Fig.r io ein Beispiel fur die Struktur, eines*BDoc ent- 
sprechend Figur 9 mit einer etwas- komplizierte- 
ren Segmentstruktur, 

Fig. 11 eine Darstellung zur Erlauterung der Prinzipien 
eines fur die Erfindung geeigneten Data -Merge - 
Verf ahrens , 
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Fig. 12 eine Prinzipdarstellung des Zusammenwirkens der 
wesentlichsten Komponenten bei der Erstdaten- 
bef ullung, 

Fig. 13 und Fig. 14 zwei Darstellungen zur Erlauterung 
eines fur die Erfindung geeigneten Verfahrens 
zur Netto-Feld-Ubertragung, 

Fig. 15 eine Prinzipdarstellung der wesentlichen Kompo- 
nenten zur Erlauterung eines Verfahrens der Da- 
t ensynchroni sat ion , 

Fig. 16 eine Prinzipdarstellung zur Erlauterung der 
Funktion eines fur die Erfindung geeigneten 
" Compare " - Modul s , 

Fig. 17 eine Prinzipdarstellung eines fur die Erfindung 
geeigneten Verfahrens zur Losung von Konflikten 
beim Daten-Update . 

Der in den Figuren beispielhaft dargestellte Anwendungs- 
fall eines erf indungsgemafien integrierten Verbundsys terns 
bezieht sich auf die Integration einer Vertriebs-EDV-L6- 
sung (Sales Force Automation; SFA) mit einem zentralen 
ERP-System. Einen Uberblick uber das Umfeld eines solchen 
Systems gibt Figur 1. 

Im Aufiendienst (Field) FD sind AuSendienstmitarbeiter 
(Sales Representative) SR tatig, die die Kunden (Custo- 
mer) C beraten und z.B. deren Bestellungen aufnehmen. 
Jeder AuSendienstmitarbeiter SR hat einen tragbaren 
Rechner, der auch als mobiler Klient (Mobile Client) MC 
bezeichnet wird und zu dem eine lokale Datenbank (Local 
Database) LD gehort . Die tragbaren Rechner bilden Knoten 
eines Netzwerkes, die nicht standig mit diesem verbunden 
sind und deswegen als Of f line -Knoten bezeichnet werden. 



Die mobilen Klienten MC stellen beispielsweise Marketing- 
Information zur Verfugung und speichern unter anderem die 
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Stammdaten (Masterdata) von Kunden und Produkten. Der Au- 
Sendienstmitarbeiter SR kann z.B. Bestellinf ormationen 
eingeben- und ist- iiber den Status of f ener und erledigter 
Bestellungen-informiert . Um diese Funktionen temporar au- 
tonom erfullen zu konnen, sind alle hierfur erforderli- 
chen Daten in der lokalen Datenbank LD gespeichert . 

Im Hauptquartier (Head Office) HO des Unternehmens befin- 
det sich ein Back-off ice-System, das vorzugsweise Online- 
Transaction-Processing erlaubt. Im dargestellten Bei- 
spielsfall handelt es sich um ein OLTP-R/3 -System. Es 
wird ohne Beschrankung der Allgemeinheit in den Zeichnun- 
gen und. im nachf olgenden Text mit diesem*Begr r iff bezeich- 
net. Es enthal< eine Datenbank OLTP--DBV Sei-ne^Stammdaten 
werden von ^Innendienstmit arbei-tern ( In-.Hojise^ Employees ) 
I HE gepf>legt.. 

Uberr ein ortliches - Ne v tzwerk^ (Local Area Network) LAN ist 
das OLTP-R/3 -System mit einem Front-off ice -Server verbun- 
den, der, ebenfalls ohne Beschrankung der Allgemeinheit, 
als (MS Middleware Server) bezeichnet ist. Auch dieses 
System hat eine Datenbank (Consolidated Database) CD. 

Mit dem MS -System konnen aufier den mobilen Kl lent en MC 
optional weitere Systeme verbunden sein. Dargestellt ist 
ein in dem Hauptquartier HO lokalisiertes extemes System 
BW, das beispielsweise als sogenanntes "Business Informa- 
tion Warehouse" die Analyse** von fur das Unternehmen be- 
deutsamen ' Verkauf sinf ormationen unterstutzt . Es *hat eine 
Datenbank BW^DB, I m .dargestellten Fall erhal-t .es^Daten 
sowohl von dem Back-off ice-Server -OLTP'R/3 als auch von 
dem MS -System. Im AuSendi ens there ich FD konnen beispiels- 
weise Kundensysteme (Customer System) CS; die zusatzliche 
Knot en in dem Netzwerk bilden, standig (online) oder tem- 
porar (offline) mit dem MS -System verbunden sein. Auf 
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diesem Wege konnen beispielsweise unmittelbare Bestellun- 
gen der Kunden ohne Mitwirkung eines Aufiendi ens t mi tarbe li- 
ters SR abgewickelt werden. Auch das Kundensystem CS hat 
eine Datenbank CS-DB. 

Das dargestellte Netzwerk enthalt somit unterschiedliche 
Datenquellen (mobile IClienten MC, OLTP-R/ 3 -System, optio- 
nale externe Systeme BW und Kundensysteme CS) , die jedoch 
nicht unabhangig voneinander sind. Sie werden durch das 
MS -System verknupft, das dafur sorgt, dafi jeder Teilneh- 
mer die fur ihn notwendige und zulassige Information er- 
halt. Im dargestellten Fall erfullt der Middleware Server 
MS zugleich diese Verkniipf ungs funk t ion und bildet den 
Zentralrechner eines aus ihm und den mobilen Klienten be- 
stehenden CRM-Systems, das ein of f line-verteiltes Daten- 
banksystem ist. Es wird mit dem Zentral-Datenbanksystem 
OLTP-R/ 3 verschmolzen. Die Grundsatze der vorliegenden 
Erfindung sind aber auch auf andere Falle der Verschmel- 
zung von Datenbanksystemen anwendbar, also insbesondere 
auf die Verschmelzung von zwei oder mehreren Zentral -Da- 
tenbanksystemen oder auf die Verschmelzung von zwei oder 
mehreren verteilten Datenbanksystemen. 

Die Datenbank MS-DB des MS -Systems enthalt samtliche fur 
seine Spezialfunktion (im Beispielsf all Customer Rela- 
tionship Management CRM) erf orderlichen Inf ormationen. 
Sie wird auch als konsolidierte Datenbank CD bezeichnet, 
weil sie den Inhalt aller lokalen Datenbanken LD der 
tragbaren Rechner (zum Zeitpunkt des letzten Datenaustau- 
sches) enthalt. Dadurch ist es moglich, die lokalen Da- 
tenbanken LD mit den erf orderlichen Daten zu versorgen, 
um insbesondere* die Bedeutung von Datenanderungen zu er- 
mitteln oder erf orderlichenf alls auch die lokalen Daten- 
banken LD wiederherzustellen. 
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Die tragbaren Rechner werden in Abstanden, beispielsweise 
am Abend jeden Tagea, z.B. uber Telef onleitungen, das 
Internet oder ein Intranet, mit dem MS-System verbunden. 
Dabei werden die seit der letzten Verbindung gesammelten 
Daten an das MS-System ubertragen. AuSerdem ubernimmt der 
tragbare Rechner bei dieser Gelegenheit seine eigenen 
verarbeiteten Daten des jeweils vorausgegangenen Zeit- 
raums und neu eingegebene Daten anderer tragbarer Rechner 
und anderer Systeme (soweit erforderlich) . 

Die Nutzdaten der miteinander verbundenen Systeme werden 
(da sie sich in dem Beispielsf all auf geschaf tliche Vor- 
gange wie Runden-?- Auf trage und dergieichen- beziehen) als 
Businessdaten bezeichnet-v. In dem OLTP-R/ 3 -System werden 
daraus Businessobjekte gebildet, die als Datencontainer 
fur, die weitere Bearbeitung„ dienen. Beispielsweise ent- 
halt ein Businessobj ekt fur^einen besfe-immten^Auftrag alle 
zu dem . Auf trag-gehorigen in der -Datenbank OLTP>-DB, gespei- 
cherten Daten, unabhangig davon, wie sie in deren logi- 
scher Struktur (in Tabellen einer relationalen Datenbank) 
vorliegen. Diese Struktur ist fur das OLTP-R/ 3 -System 
bekannt und wird in ahnlicher Weise auch in anderen Back- 
off ice-Systemen eingesetzt. 

Die Steuerdaten, die zur Verarbeitung der Businessdaten 
in den beteiligten Systemen erforderlich sind, werden in 
einem logisch gesonderten Teil der jeweiligen Datenbanken 
gespeichert, der als Repository bezeichnet wird. 

Hinsichtlich der Ubertragung- an^das-OLTP-R/3 -System sind 
die Ubertragungskriterien weitgehend statisch. Sie werden 
einmal festgelegt und bleiben unverandert, soweit nicht 
Anderungen in den Geschaf tsablauf en des jeweiligen Unter- 
nehmens in grofieren Zeitabstanden eine Anderung erfor- 
dern. 



Dagegen ist die Datenubertragung an die tragbaren Rechner 
hochgradig dynamisch. Beispielsweise andem sich die Zu- 
standigkeiten der Aufiendienstmitarbeiter fur bestimmte 
Verkauf sbezirke moglicherweise haufig. Aus solchen Ande- 
rungen ergibt sich jeweils eine Anderung der Kriterien 
fur die Datenubertragung, weil jeweils nur das Minimum 
der notwendigen Da ten an die tragbaren Rechner ubertragen 
werden soil . Aus dem gleichen Grund mussen obsolet gewor- 
dene Daten in den tragbaren Rechnern geldscht werden, 
wahrend neuerdings relevant gewordene Daten hinzugefugt 
werden mussen. die Datenubertragungskriterien werden vor- 
zugsweise als sogenannte Publikationen und Subskriptionen 
in dem MS-System gespeichert. Der ProzeS des Updatens der 
Obertragungskriterien und der Daten an die mobilen Klien- 
ten MC wird nachfolgend als Realignment bezeichnet. 

Da bestimmte Daten fur mehr als einen tragbaren Rechner 
von Bedeutung sind, ist es notwendig, sie bei der Uber- 
tragung an die tragbaren Rechner zu kopieren. Diese Uber- 
tragung an mehr als einen Empf anger wird nachfolgend als 
Replication bezeichnet. 

Figur 2 gibt einen Uberblick uber die Architektur des MS- 
Systems. Auf der linken Seite sind die mobilen Klienten 
MC und unten das OLTP-R/ 3 -System und das ex t erne System 
BW dargestellt. Die ubrige Figur zeigt das MS-System ein- 
schlielSlich seiner Datenbank CS und eines zugehorigen 
Nachrichtenubermittlungsservers (Message Transfer Server) 
MTS . 

Das MS-System ist vorzugsweise auf Basis der R/3 Techno - 
logie implement iert . Demzufolge konnen seine Funktionen 
auf mehrere Maschinen verteilt sein, insbesondere konnen 
eine gesonderte Maschine fur die Datenbank und eine oder 
mehrere Maschinen zur Bearbeitung von Anf orderungen 
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eingesetzt werden. Die Maschine, auf der der Nachrichten- 
ubermittlungsserver lauft, wird insgesamt als Administra- 
tions station (Admin Station) AS bezeichnete*. Der-Nachrich- 
tenubermittlungsserver MTS und die zugehor±ge Administra- 
tionskonsole (Admin Console) AC sind vorzugsweise auf ei- 
ner Maschine, die unter Windows NT lauft, installiert. 
Die daraus resultierende mogliche Maschinengrenze ist in 
der Figur gestrichelt dargestellt. 

Fur den Transport der Daten in dem Front -office System 
werden Datencontainer eingesetzt, die als BDocs bezeich- 
net werden. Sie dienen auch der Kommunikation zwischen 
den "mobilen Klienten MC und dem ^MS ^System. . Dalaei- sind 
verschiedene*.;Arben von BDocsr»zu oinfcerseheiden^ 

Trans akt^ionelle BDocs werdeht behut^zt'^ um^Transak- 
tionse-2?gebn^ss,e und^Statusi-nf ^rmatipnen^zwischen den 
tragb.aren^Re'fehneni' "MC* und&dem Front - of f'ic.ejr Server 
CRM-MS zu ubertragen. Si'e-konnen -wie folgt weiter un- 
teassc-hd-eden^ werden : 

Trans akt ions -BDocs transport! eren Transaktionsergeb- 
nisse von den mobilen Klienten MC zu dem MS -System. 
Der mobile Klient bildet dabei ein BDoc, das das Er- 
gebnis der Transaktion enthalt und sendet es an das 
MS -System. 

Bestatigungs-BDocs (Confirmation BDoc) zeigen die er- 
fotgreiche Verarbeitung eines Transak-tdons- BDocs 
durch das f MS- System an. Wenn die Verarbeitung eines 
Transak-feLonsssBDocs erfblgreich ist, wird .der Status 
des BDoc^entsp>rechend geandert und das BDole wi-rd an 
den mobilen Klienten, von dem es versandt wurde, als 
Bestatigungsnachricht zuruckgeschickt . Diese Bestati- 
gungsnachricht enthalt auch zusatzliche Daten, die 
beispielsweise von dem OLTP-R/3 -System zur Verfugung 
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gestellt wurde oder geanderte Werte der konsolidier- 
ten Datenbank CD. Das Bestatigungs-BDoc enthalt dabei 
entweder nur geanderte Werte oder alle Werte. 

Import -BDocs transport ieren Transaktionsergebnisse 
eines anderen mobilen Klienten MC oder eines externen 
Systems von dem MS -System an den mobilen Klienten MC. 
Auch die Import -BDocs enthalten nur geanderte Werte 
oder alle Werte. Import -BDocs werden auch benutzt, urn 
Datenanderungen, die von anderen Que 11 en als den mo- 
bilen Klienten MC stammen, von dem MS -System an die 
mobilen Klienten zu ubertragen. 

Fehler-BDocs (Error BDocs) zeigen an, da£ ein Fehler 
in dem MS -System bei der Verarbeitung eines Transak- 
tions-BDocs aufgetreten ist. In diesem Fall wird ein 
Fehlersegment in das BDoc eingefugt und es wird als 
Fehler -BDoc an den aussendenden mobilen Klienten MC 
zuruckgeschickt . Das Fehlersegment kann unterschied- 
liche Records enthalten, urn verschiedene Fehlerkondi- 
tionen anzuzeigen. Das Fehler-BDoc enthalt auch die 
ursprunglichen Werte als "Bilder des vorherigen Zu- 
standes" (before images) . Alle Felder sind mit dem 
aktuellen Inhalt der konsoiidierten Datenbank- CD ge- 
fiillt . 

Service-orientierte BDocs werden benutzt, urn Binarda- 
ten von dem MS -System an den tragbaren Rechner MC zu 
ubertragen . 

Massenorientierte BDocs (Bulk oriented BDocs) werden 
benutzt, um grofie Datenmengen von dem MS-System zu 
dem mobilen Klienten MC zu transportieren, z.B. bei 
der Erstdatenbef ullung . 
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Weiter sind die BDocs hinsichtlich der transport iert en 
Inhalte in unterschiedliche BDoc-Typen zu dif f erenzieren. 



Eine nahere Erlauterung der BDocs und insbesondere deren 
Struktur wird weiter unten gegeben. 

Die Datenverarbeitung in dem MS-System erfolgt mittels 
Funktionsmodulen, die als "Service" bzw. als "Adapter" 
bezeichnet werden. Ein Service stellt eine bestimmte 
Funktion, die auf eih BDoc angewendet werden kann, zur 
Verfugung. Ein -Adapter- is.fc_ei*n spez-ieller- Typ von Ser- 
vice, de r, zusat z l.i ch ;di e -yearbindiing-* zu- , e inenv*Sys t em au - 
Seasha-ib des^MS^- Systems ^erropgllchfe^ 

Die Kommuni?kat?ion^de^^^ dem 
Middleware - Server^MS*Tal*s auch -mi t -ihrer- 1 oka-Ken Datenbank 
LD erfolgt ausschlieSlich uber eine Transaktionsschicht 
(Transaction Layer) TL. Dresbezuglich wird erganzend auf 
die deutsche Patentanmeldung 19928035.5 verwiesen. 

Die Funktionen der in Figur 2 dargestellten Komponenten 
des MS-Systems lassen sich wie folgt charakterisieren. 

Der Nachrichtenubermitt lungs server MTS empfangt BDocs von 
den mobilen Klienten MC und ubermittelt BDocs an diese. 
Die Datenubertragung wird jeweils durch einen mobilen 
Klienten MC eingel*eitet . Beispielswei>se kann hierzu die 
Kommunikatedons t echnologie DCOM^von-MA-crosof t verwende t 
werden. 

Die Ubertragurig von BDocs von den mobilen Klienten MC an 
das MS-System erfolgt mittels eines Adapters fur einge- 
hende Nachrichten (Inbound Message Adapter) IMA, wahrend 



BDoc-Typen konnen beispielsweise "Kunde", " 
sein. 



Auftrag" etc. 
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in umgekehrter Richtung ubertragene Nachxichten mittels 
eines Adapters fur ausgehende Nachrichten (Outbound Mes- 
sage Adapter) OMA ubertragen werden. Diese Datenubermitt - 
lungen erfolgen mittels eines Protokolls, das als qRFC 
(queued Remote Function Call) bezeichnet wird. Dabei han- 
delt es sich um ein remote function call Protokoll, bei 
dem queues verwendet werden, um die Reihenfolge der Bear- 
beitung festzulegen. 

Die zentrale Komponente des MS -Systems ist die FluSsteue- 
rung (Flow Control) FC. Die Flufisteuerung FC bewirkt die 
Verarbeitung der BDocs, indem sie eingehende BDocs in der 
richtigen Reihenfolge zu den Services und Adapt em leitet 
und wenn erforderlich eine Fehlerbehandlungsprozedur aus- 
lost. Dies erfolgt fur alle Services und Adapter uber das 
gleiche Interface. Der Haupt parameter in dem Interface 
ist wiederum ein BDoc. Der Flow ist BDoc-Typ spezifisch 
in einem Steuerdatenspeicher (Repository) definiert. 

Externe Systeme wie das OLTP-R/ 3 -System und das BW-System 
sind jeweils uber einen spezifischen Adapter OI/TP-AD bzw. 
BW-AD mit dem MS-System verbunden. Jedes externe System 
hat also seinen eigenen Adaptertyp, der ebenfalls BDoc- 
spezifisch in dem Reporsitory definiert ist. Das Proto- 
koll und die Datenstruktur des Ubertragungskanals zwi- 
schen einem Adapter und dem daran angeschlossenen exter- 
nen System ist fur den Typ des externen Systems spezi- 
fisch. 

Ein Datenbankservice (Consolidated Database Service) CDS 
dient zur Speicherung entsprechender Daten in der konso- 
lidierten Datenbank CD. Der Service CDS fuhrt keine Pru- 
fungen auf Datenkonsistenz durch, wenn er Daten in die 
Datenbank CD schreibt . Derartige Checks mussen von den 
Komponenten durchge fuhrt werden, die Daten an das MS- 
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System ubertragen (beispielsweise die mobilen Klienten MC 
oder das OLTP-R/3 -System) . Zum Lesen der Datenbank CD 
verwenden die anderen Services nicht den Service CDS, 
sondem einen in der Figur nicht dargestellten Extrakt- 
Handler, der von Services, Adaptern oder anderen Handlern 
aufgerufen wird. 

Der Replications- und Realignment Modul RRM hat zwei 
Hauptaufgaben. Der Replicationsteil ubernimmt bearbeitete 
BDocs und bestimmt deren Empf anger. Zur schnelleren Bear- 
beitung wird die hierzu erf orderliche Information aus 
Lookup -Tabell en gelesen. Wenn der Replicationsteil fest- 
stellt, daS die Lookup -Information infolge eines gegen- 
wartig verarbeiteten BDocs geandert werden mufi, lost er 
den Real ignment -handler- aus . Der ^Realignment ^Handler er- 
zeugt die erf orderliche Lookup- Information, ^ indem.er die 
Rep 1 i c a t i ons r ege In auswerte t . Au£e rdem ~ s t ell,t::der Rea - 
lignment- Handler neue Daten^f ur Empf ahger^zur._Verf ugung 
und gibt Befehle zur Loschung unndtiger Daten. Hierzu be- 
dient er sich des Extract Handlers. 

Die Administrationskonsole AC wird benutzt, um den MS- 
Server kundenspezif isch anzupassen- (Customizing) und das 
Gesamtsystem hinsichtlich des logischen Datenflusses zu 
administrieren . 

Figur 3 zeigt am Beispiel eines Daten-Upload-Vorgangs 
einen typischen Ablauf der FluSsteuerung des MS-Systems. 
Dabei sind die von dem Nachrichtenprozessor (Message Pro- 
cessor) MP der FluSsteuerung FC durchgefuhrten Schritte 
in der mit MP-FC uberschriebenen Spalte dargestellt. Die 
erste und dritte Spalte zeigen die von Services durchge- 
fuhrten Bearbeitungsschritte . In der letzten Spalte sind 
Bearbeitungsschritte angegeben, die von dem OLTP-R/3 -Sy- 
stem ausgefuhrt werden. 




Der FluS beginnt/ wenn der Nachrichtenubermittlungsserver 
MTS (uber RFC) den Adapter fur eingehende Nachrichten IMA 
aufruft, weil ein neues BDoc empfangen wurde. Der Adapter 
fur eingehende Nachrichten IMA startet den Nachrichten- 
prozessor MP-FC. 

Der auszufuhrende FluS wird von dem Nachrichtenprozessor 
MP bestimmt. Im wesentlichen sind zwei Flufiverlaufe zu 
unterscheiden, einer fur die Bearbeitung von BDoc-Typen, 
die zumindest zum Teil fur das OLTP-R/ 3 -System relevant 
sind, und einer fur andere BDocs (die nur innerhalb des 
MS -Systems zirkulieren) . 

In Abhangigkeit von der in einem Repository fur die je- 
weiligen BDoc-Typen gespeicherten FluSdef inition bestimmt 
der Nachrichtenprozessor MP den ersten Service bzw. Adap- 
ter, der aufgerufen wird. Fur Typen von BDocs, die (zu- 
mindest zum Teil) fur das OLTP-R/ 3 -System relevant sind, 
wird als erster Service der OLTP-R/ 3 Adapter OLTP-AD auf- 
gerufen. Fur andere BDocs wird der OLTP-R/3 Adapter nicht 
aufgerufen. Die Entscheidung, ob der OLTP-R/3 Adapter fur 
einen Typ von BDoc aufgerufen wird, ist bei der Festle- 
gung des Flusses getroffen worden, wird also nicht inner- 
halb des Flusses getroffen. 

Wenn der OLTP-R/3 Adapter OLTP-AD aufgerufen wurde, be- 
stimmt er, ob das BDoc tatsachlich fur das OLTP-R/3 -Sy- 
stem relevant ist. Dies ist nicht notwendigerweise der 
Fall, weil die Relevanz fur das OLTP-R/3 -System nicht nur 
von dem Typ des BDoc abhangt, sondern auch von dessen In- 
halt abhangen kann. Ein Bei spiel sind BDocs des Business- 
objekt-Typs "Kunde". Wenn derartige BDocs Inf ormationen 
uber Kunden enthalten, werden sie an das OLTP-R/3 -System 
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geschickt. Wenn sie jedoch Inf ormationen uber Vertriebs- 
kontakte enthalten, werden sie nur in dem MS-System ge- 
spei chert . 

Wenn der OLTP-R/3 Adapter festgestellt hat, dafi ein BDoc 
fur das OLTP-R/ 3 -System relevant ist, sendet er einen 
Aufruf dorthin und unterbricht den laufenden Flufi. Nach 
Beendigung der Bearbeitung in dem OLTP-R/ 3 -System sendet 
dieses einen Aufruf an den OLTP R/3 Adapter , der das Er- 
gebnis ubernimmt und den FluB wieder startet, indem er 
den Nachrichtenprozessor MP der Flufisteuerung FC aufruft. 

Der Nachrichtenprozessor MP.^FC Cermi-ttelt , welpher Service 
als n&chsfees* auf zuruf en -istv Falls *der« OLTPxR/a Adapter 
OLTF-AB* fesfcgesteMt hat,, daiS^das »BDp.c ni entire 1 e van t fur 
das*OLTP-R/«3 - Sys t em -is t-./ fc g*bt^e*tedie ; Konterplle .an den 
Nachrichtenprozessor MP^Fe^;zuruekr^, der^aueh*:inMdiesem 
Fall den* nachsfcen auf zuru£enden Service bestimmt . 

Normalerweise wird nach dem OLTP-R/3 Adapter der Daten- 
bank- Service CDS aufgerufen. Er macht die in dem BDoc 
enthaltenen Daten in der konsolidierten Datenbank CD per- 
sistent. 

Wenn die Daten erfolgreich in die konsolidierte Datenbank 
CD geschrieben wurden, wird in der Regel der Replikation- 
und Realignment -Service RRM aufgerufen. Eine Funktion 
dieses Services besteht darin, zu prufen, ob das BDoc -die 
Replikationsinf ormation beeinflufit. Falls dies-der Fall 
ist, wird fur den Realginment -Handler ei*n AuCtrag er- 
zeugt, die Lookup -Information zu aktualisieren und ein 
BDoc zur Verteilung der Businessdaten zu erzeugen. Die 
zweite Aktion des Replikation- und Realignment -Service 
RRM besteht darin, dem aktuellen BDoc eine Empf angerliste 
hinzuzuf ugen . 
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SchlieElich wird der Adapter fur abgehende Nachrichten 
OMA aufgerufen, urn die BDocs fur die Ubermittlung an ihre 
Empf anger mittels des Nachrichtenubermittlungsservice MTS 
vorzubereiten . 

Fur den Fall, da£ der Upload fehlschlagt, wird ein Re- 
ject-Service aufgerufen. Das BDoc wird als Fehler-BDoc 
(also als ein BDoc, welches Fehlerinf ormationen enthalt) 
markiert. Bei der Update -Operation liest der Reject-Ser- 
vice die gultigen Werte aus der konsolidierten Datenbank 
CD. Bei alien Operationen werden die jeweils vorherigen 
Zustande der mobilen Klienten MC markiert. Das BDoc wird 
dann an den tragbaren Rechner, von dern es ausgesandt 
wurde, zuruckgesandt . Dort wird die entsprechende Trans - 
aktion erneut ausgefuhrt. 

In Figur 3 ist - mit Ausnahme des Re j ect- Service RS - nur 
der Erfolgs-Pfad eingezeichnet . Selbstverstandlich ist 
auch eine Fehlerbearbeitungs routine vorgesehen, die hier 
jedoch nicht naher beschrieben wird. 

Anhand von Figur 4 wird die Struktur der BDocs naher er- 
lautert . Darin zeigt der obere Teil die Struktur der De- 
finition des BDoc-Typs, die in dem Repository des MS-Sy- 
stems abgespeichert wird. Die Struktur des BDocs selbst 
ist im unteren Teil dargestellt . 

Die Definition des BDoc-Typs befindet sich nur in den 
Segment -Def initionen BDoc-SD des BDoc-Korpers (BDoc -Body) 
BDoc-BD.. Der BDoc -Header BDoc-H und das Fehler segment 
(Error Segment) ES sind nicht spezifisch fur den Typ des 
BDocs und deswegen in der Definition des BDoc-Typs " nicht 
enthalten. Der BDoc -Header BDoc-H enthalt Information von ' 
allgemeinem Interesse, wie beispielsweise die Art 
(Transaktion, Bestatigung, ...) und den Typ ("Kunde", 
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"Auftrag" ...) des BDocs, dessen Absender (mobiler Klient 
MC und Benutzer SR) , eine Zeitmarkierung und eine BDoc- 
Identd f i - ka t i on . 

Der Daten-Record (Data Record) DR enthalt die eigentli- 
chen Daten. Die Struktur ist in der Definition des zuge- 
h6rigen Datensegmentes (Data Segment) DS definiert. Fur 
transaktionale BDocs werden die Segmente von einer Art 
von Tabellenansichten der tatsachlichen physischen Tabel- 
len gebildet. 

Wahrend die Segmente in der Definition des BDoc-Typs 
hierarchisch strukturiert sind, gibt es bei der physi- 
schen Wiedergabe der BDocs keine derartige .Hierarchie . 
Die hierarchische Abhangigkeit ist in, den BDocs > dadurch 
enthalten, daS. die Daten-Records* DR abhangiger- Segmente 
den Schlussel ihrer ubergeordnefeen Daten-Records enthal- 
ten. Im Fall transaktionaler -BDocs ist daruber r x hinaus 
(abgesehen von dem optionalen Fehlersegment ES mit Feh- 
ler-Record (Error Record) ER) ein unabhangiges Segment 
vorgesehen, dafi als Root-Segment bezeichnet wird. 

Das Root -Segment enthalt nur einen einzigen Daten-Record. 
Diese Bedingung mu& eingehalten werden, urn sicherzustel - 
len, daS die in dem BDoc enthaltene Information individu- 
ell an die jeweiligen Empf anger ubermittelt oder in ande- 
rer Weise bearbeitet werden kann. Beispielsweise darf in 
einem transaktionalen BDoc des. Typs "Kunde" nur Informa- 
tion uber einen einzigen Kunden gespeichert sei-n, damit 
die Kundeninformation individuell und gezielt fur jeden- 
einzelnen Kunden den entsprechenden Empfangern zugeleitet 
werden- kann. Die Daten-Records nachgeordneter Segmente 
enthalten abhangige Daten, beispielsweise uber die Ma- 
schinenausstattung des Kunden. Hier konnen selbstver- 
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standlich zu einem Segment mehrere Records vorhanden 
sein. 

Die Datenbereiche haben eine festgelegte Lange. Sie be- 
stehen aus einem Schlussel und Datenf eldern. Wenn sie 
eine Losch- Information enthalten, enthalt nur das Schlus- 
selfeld gultige Daten. Wenn sie "Insert" oder "Update" - 
Inf ormationen enthalten, enthalten entweder alle Felder 
gultige Daten oder unveranderte Felder enthalten einen 
Voreinstellungswert (beispielsweise 0,0). Urn anzuzeigen, 
ob ein Feld gefullt oder unbenutzt ist, werden sogenannte 
"Sende-Bits" benutzt. Primarschlussel und -felder, die 
bei Replication und Realignment be rucks ichtigt werden 
mussen, werden immer gesendet, (unabhangig davon, ob sie 
geandert wurden) , da sie den Datensatz eindeutig identi- 
fizieren. Die Sende-Bits werden nur gesetzt, wenn der 
Wert tatsachlich geandert wurde. 

Wenn geandert e Daten an das MS -System ubermittelt* werden, 
konnen die Werte, die der mobile Klient MC vor der Ande- 
rung hatte, fur das MS -System von Interesse sein. Solche 
"Bilder des vorhergehenden Zustands" (before images) wer- 
den in eigenen Datenbereichen ubermittelt, die entspre- 
chend gekennzeichnet sind. 

Service-orientierte BDocs werden verwendet, um Daten des 
externen Systems BW und Installationsdateien an einen mo- 
bilen Klient en MC zu ubermitteln. Der Korper eines Ser- 
vice-orient ierten BDoc besteht aus einem Root -Segment mit 
allgemeiner Information und einem Memo-Segment, das die 
binaren Daten enthalt . 

Massenorientierte BDocs werden fur die anfangliche Ein- 
richtung eines mobilen Klienten (Initial Client Setup) 
und fur den Datentransport wahrend des Realignment 
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benutzt. Auch massenorientierte BDocs sind Typ-spezif isch 
definiert (also z.B. fur den Objekttyp "Kunde") .Sie un- 
te^ta.egen jedoch- nicht der Restriktion, dafi in* ihrem 
Root-Segment nur ein Record enthalten sein darf . Bei- 
spielsweise kann also ein massenorientiertes BDoc die Da- 
ten einer Vielzahl von Kunden auf einmal ubertragen. 

Der OLTP-R/3 Adapter OLTP-AD verbindet das OLTP-R/3 -Sy- 
stem mit dem MS-System. Er dient dazu, Daten in beide 
Richtungen zu transport ieren. Wenn Daten, beispielsweise 
die Bestellung eines Kunden, in den mobilen Klienten MC 
eingegeben und dann an das OLTP-R/3 -System weitergeleitet 
werden; wird dies als "Upload" bezei«chnefc . WennVDafeen in 
das, OLTP-R/3 -System- eingegeben und-;von^dor«t^zu^dem MS-Sy- 
stem weitergeleitet we-rdenv wird^dies -als ^Download be- 
ze&ehnet~v 

Es'&sind drei**Typen von-' ^Downloads zu untersch'ei'den. Mit- 
tens einer Erstdatenbef ullung (Initial Download) wird die 
konsolidierte Datenbank CD des MS-Systems zu. Beginn des 
Betriebs mit Daten von dem OLTP-R/3 -System gefullt. Ein 
Deltadownload findet statt, wenn Online-Benutzer Daten in 
das OLTP-R/3 -System eingeben und das geanderte Objekt an 
das MS-System weitergeleitet wird. Ein derartiger Delta- 
download ist nicht fur alle Datenarten moglich. Sofern 
diese Funktion nicht zur Verfiigung stent wird ein dritter 
Downloadmechanismus eingesetzt, der nachfolgend als Syn- 
chronisationsmechanismus bezeichnet wird. 

Die bei dem Upload- und dem Deltadownload wi-rksamen Kompo- 
nenten^ des MS -Systems -und des OLTP-R/3 -Systems sind in 
Figur 5 dargestellt. Bestandteile des MS-Systems sind die 
Flufisteuerung zur Koordination der zur Bearbeitung der 
BDocs notwendigen Prozefischritte , der OLTP-R/3 Adapter 
OLTP-AD, sowie drei Agent en, die als Schliisselgenerator 
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(Keygenerator) KG, Mapping-Agent MA und Merging -Agent MEA 
bezeichnet werden. Diese Agenten erfullen Hilf sf unktionen 
fur den OLTP-R/3 Adapter. 

Bestandteil des MS-Systems ist ein Calling Frame CF zum 
Aufruf von Standard -BAP Is (Business Application Program- 
ming Interface) , die wahrend der Bearbeitung der BDocs 
aufgerufen werden konnen. Die Standard -BAP Is ruf en Up- 
date - Funk t i onsmodu 1 e UFM auf, urn Anderungen persistent zu 
machen. Diese Update -Funkti on smodule UFM werden auch von 
Dialog-Programmen DP aufgerufen. 

Die Update-Funktionsmodule UFM erzeugen bei jeder Ande- 
rung ein Event, das an den Event Distributor ED ubermit- 
telt wird. Als Reaktion auf eine solche Ubermittlung 
startet der Event Distributor alle Subskribenten. Unter 
anderem wird dadurch der als Subskribent eingetragene Er- 
gebnisubermittler (Results Sender) RS aufgerufen. Die mo- 
difizierten Daten werden von dem ErgebnisCtbermittler RS 
an das MS-System ubermittelt. In einem Speicherbereich 
Schlussel -Ref erenzen (Key References) KR sind Schlussel 
Kj^g des Front-off ice -Systems MS und Objekt- Ref erenzen OR 
gespeichert . Ein Speicherbereich Erganzungsdaten (Addi- 
tional MS-Data) AMD entha.lt Daten, die durch das OLTP- 
R/3 -System transport iert werden mussen, aber fur dieses 
selbst nicht relevant sind (beispielsweise Schlussel des 
Front-off ice-Systems) . Von dem MS-System werden keine 
Daten an das OLTP-R/3 -System ubermittelt, die fur dieses 
nicht relevant sind. 

Der Calling Frame CF und der Ergebnisubermittler RS sind 
die einzigen Bestandteile des OLTP-R/3 -Systems, die fur 
die hier beschriebenen Funktionen zusatzlich implemen- 
tiert wurden. 
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Ein Upload erfolgt f olgendermaSen. In dem MS -System wird 
ein BDoc bearbeitet . Als Schritt dieser Bearbeitung wird 
der OLTP -Adapter OLTP - AD aufgerufen. Er entscheddet; ob 
das BDoc fur das OLTP -R/ 3 -System relevant ist. Falls es 
relevant ist, markiert der BAPI Caller BC das BDoc ent- 
sprechend. Dadurch wird gewahrleistet , dafi nicht auch an- 
dere BDocs in der gleichen queue bearbeitet werden. Auch 
solche fur das OLTP -R/ 3 -System irrelevante BDocs mussen 
in der queue sein, weil moglicherweise eine Abhangigkeit 
eines BDocs in der queue zu vorausgehenden BDocs besteht . 
Die Struktur des BDocs wird auf die Parameters trukturen 
des entsprechenden BAPI des OLTP -R/ 3 -Systems gemappt . 
Dann wird"* der Calling* Frame dieses* BAP/I in dem-OLTP-R/3- 
Sysfeem* aufgerufen . 

Eine^erste Aufgabe des^Ca v lIXng Frame .bestiehts^darin/ eine 
Doppe*lbearbeitung zu^ver^eiden^ .Wennngemafisidem^BAPI ein 
neues^Objekt erzeugt- werden#so'M, prufvt*rder Calling 
Frame, ob das Objekt schon existiert und auf eine ent- 
sprechende Anforderung des MS-Systems erzeugt wurde. 
Falls dies der Fall ist, werden statt der Neuerzeugung 
eines Businessobjektes die bereits bearbeiteten Daten ex- 
trahiert und an das MS-System zuruckubermittelt . Eine 
zweite Aufgabe des Calling Frame besteht darin, das er- 
forderliche Mapping zwischen den Schlizsseln und Objektre- 
ferenzen des MS-Systems und den Schlusseln und Objekt-Re- 
ferenzen des OLTP-R/3 -Systems sicherzustellen. Eine 
dritte Aufgabe ist das Handling der Commit-Zyklen. Da- 
durch wird^ sichergestellt , dafi. die BAPI-Veraisbeiitung in 
einem einzigen* Commit -Zyklus ablauf t . Inf olgedessen fin- 
det das Abspeichern der Daten in dem Back-off ice -System 
OLTP-R/3 und deren Ubergabe an das Front-off ice-System MS 
in einer gemeinsamen Verarbeitungsarbeit statt . 



Die Hauptfunktion des Calling Frame CF besteht darin, das 
Standard-BAPI SB aufzurufen. Zu diesem Zweck enthalt der 
Calling Frame alle Inf ormationen, die erforderlich sind, 
um die Struktur eines von ihm empfangenen BDoc in die 
Struktur der universellen Schnittstelle BAPI umzusetzen. 
Das BAPI bearbeitet die Daten des BDoc und enthalt Auf- 
rufe zu Update -Funktionsmodulen UFM. Diese Funkt ion s mo- 
dule beginnen mit ihrer Arbeit, wenn der Calling Frame 
einen Commit-Bef ehl an das Standard-BAPI gibt . Die Up- 
date -Funkt ionsmodule machen die Datenanderungen auf der 
Datenbank persistent. Aufierdem erzeugen sie ein Event, 
das an die Abonnenten des Event -Distributors ED verteilt 
wird. Einer dieser Abonnenten ist der Ergebnisubermittler 
RS. Er erhalt die geanderten Daten als Parameter des er- 
zeugten Events, mischt sie mit den Erganzungs daten AMD 
und ubermittelt sie an das MS-System. 

In dem MS-System mapped ein Ergebnis- Save -Agent RSA die 
empfangenen Ergebnisse zuruck" in BDoc- Struktur en . Der 
Merging Agent MEA mischt die aus dem OLTP-R/ 3 -System kom- 
menden Ergebnisse mit den BDocs in dem MS-System. Danach 
startet der Ergebnis -Save -Agent RSA die FluSsteuerung fur 
die BDocs, indem er den Status der BDocs andert in "OLTP 
Complete" . 

Hinsichtlich der FluSsteuerung zur Bearbeitung der BDocs 
wird erganzend auf die obigen Erlauterungen anhand von 
Figur 3 verwiesen. 

Der ProzeS eines Deltadownload (Uberfuhrung von Daten, 
die direkt in das OLTP-R/ 3 -System eingegeben wurden und 
dann in das MS-System uberfuhrt werden) ist dem Upload 
sehr ahnlich. Figur 6 zeigt' die vollstandige Flufisteue- 
rung bei der Bearbeitung eines BDoc, das infolge' eines 
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Deltadownload erzeugt wurde. Die Architektur entspricht 
Figur 5. 

Der Innendienstmitarbeiter IHE, der online uber das Dia- 
logprogramm DP mit dem OLTP-R/3 -System kommuniziert , er- 
zeugt ein Businessobjekt. Das Dialogprogramm DP ruft die 
Update-Funktionsmodule UFM auf und beginnt mit seiner Ar- 
beit. Die Update-Module erzeugen die Events und der Er- 
gebnis-Ubermittler RS ruft den Ergebnis- Save -Agent en in 
dem MS-System auf. Im Gegensatz zu dem Upload-ProzeS sind 
keine zusatzlichen CRM-Daten vorhanden, die der Ergebnis- 
ubermittler RS an das MS-System ubermitteln mufite. Feh- 
lende CRM-Daten, wie beispielsweise^ .CRM^Schlussel^ fur neu 
erzeugtie Objekte we-ctden von- dem. Schlusselgeneiiafcor KG er- 
zeugt der sei«nerisei£s ln yon demj.Erlge^bnis^Sa^e^Agent en RSA 
getr.igge-st wird.* Fu^di^won^^ 

genea^Daten wird^ein BDo e^e r-z eug t ^ undnd i e Flufi- 
s t euerung'ww>rd- gestar-tet y um^den^enfcsprechenden S t eue - 
rungsfluE, wie in Figur 6 dargestellt, abzuarbeiten. 

Um vor Beginn des produktiven Betriebes die Datenbank CD 
des MS -Systems zu full en, ist eine Erst da tenbeful lung 
(Initial Download) notwendig. Die Businessobjekt-Klassen, 
die he runt erge laden werden soil en, werden wahrend der 
kundenspezif ischen Anpassung des Systems bestimmt. AuiSer- 
dem konnen Exemplare von Businessobjekt en in Abhangigkeit 
von bestimmt en Attribut-Werten gefiltert werden. SchlieS- 
lich besteht die Moglichkei-t , spezielle Exits (Customer 
Exits) zu benutzen. 

Figur 7 zeigt die Architektur der fur die Erstdatenbef ul- 
lung verwendeten Komponenten. Ein Erstbeful lungs trigger- 
agent (Initial Download Trigger Agent) IDTA wird vor Be- 
ginn der Produktionsphase von dem System- Administrator 
gestartet, um die Erstdatenbef ullung einzuleiten. Er ruft 
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einen OLTP -Download Triggeragent (OLTP Download Trigger 
Agent) ODTA auf . Das Triggern wird mittels qRFC bewirkt. 
Dadurch wird sichergestellt , daS der Erstbef ullungsvor- 
gang genau e initial durchgef uhrt wird. Der OLTP -Download 
Triggeragent ODTA ruft fur ausgewahlte Klassen von Bu- 
sinessobjekten Ext rakt or -Masters EM auf, die ihrerseits 
R/3 Extraktoren EXT aufrufen. Der Unterschied zwischen 
einem Ext rakt or -Master EM und einem Ext rakt or EXT besteht 
darin, daS der Ext rakt or -Master eine spezifisch auf die 
Kooperation mit dem MS -System abgestimmte Komponente ist, 
wahrend die Extraktoren EXT auch in anderem Zusammenhang 
in dem OLTP -R/3 -System verwendet werden. 

Auf Basis der von den Extraktor-Masters ubernommenen Fil- 
terkriterien wahlen die Extraktoren EXT Objektdaten aus 
der OLTP -Datenbank OLTP-DB aus. Daruber hinaus liefert 
der Ext raktor -Master auch Inf ormationen uber zu bearbei- 
tende Tabellen, so daS nicht notwendigerweise vol Is tan - 
dige Objekte extrahiert werden mussen. Der jeweilige Ex- 
traktor-Master ubermittelt die ausgewahlten Objekte an 
den Ergebnisubermittler RS. Wie erwahnt, kann mittels 
spezifischer Exits in dem Ergebnisubermittler eine zu- 
satzliche Filterung durchgef uhrt werden. 

Der Ergebnisubermittler RS ubermittelt die Businessob- 
jekt-Daten an den BAPI-Ergebnis- Save -Agent en RSA. Er ruft 
die Agenten fur das Mapping MA, fur die Schlusselerzeu- 
gung KG und einen Massenspeicherungsagenten fur die kon- 
solidierte Datenbank (Bulk CDB Agent) BCA. Der Mapping- 
Agent wandelt die Strukturen des OLTP -R/3 -Systems in 
Strukturen des MS -Systems urn. Der Schlusselgenerator er- 
zeugt MS-Schlussel fur diejenigen Objekte, die nur einen 
OLTP-R/3 Schlussel "haben. Der Massenspeicheragent BCA 
schreibt die Daten der Businessobjekte in die konsoli- 
dierte Datenbank DB. Der Unterschied zwischen dem Massen- 
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speicheragenten BCA und dem konventionellen Datenbank- 
service CDS des MS-Systems besteht darin, daS der erstere 
mehrere Objekte gleichzeitig verarbeiten kann, wahrend 
letzterer jeweils nur Daten eines einzelnen Businessob- 
jekts verarbeiten kann. 

Urn eine gute Performance sicherzustellen, werden mehrere 
Klassen von Businessobjekten gleichzeitig heruntergela- 
den. Dies geschieht allerdings nur fur voneinander unab- 
hangige Klassen von Objekten. Soweit Objekte von anderen 
Objekten abhangen (beispielsweise "Auftrage" von "Kun- 
den n ) werden sie in entsprechender Reihenfolge nacheinan- 
der heruntergeladen. Dabei werden die Objekte nicht auf 
der Ebene der Exemplare (Instances), sondern.auf der 
Ebene der Klassen heruntergeladen, urn in, die gewunschte 
Reihenfolge 1 gebracht ;;zu werdem 

Die Ext raktoren" ext rani eren die Daten aus der^OLTP- 
R/3 Datenbank. Wie erwahnt, werden sie auch fur andere 
Applikationsbereiche (beispielsweise eine externe Anwen- 
dung BW) verwendet . 

Die Verwendung der Extraktoren umfaSt zwei Schritte. In 
dem ersten Schritt werden Filterkriterien an einen Ex- 
traktor ubergeben. Dieser bestimmt die Schliissel aller 
' Businessobjekte, die den Filterkriterien entsprechen. In 
einem zweiten Schritt wird der Extraktor-Master EM mit 
der Schlusselliste aufgerufen, um die eigentliche Infor- 
mation zu lesen. Er holt mittels der Extraktoren die in 
dem Aufruf spezif izierten Daten von den Tabellen in' der 
fur die weitere Bearbeitung als BDoc erf orderlichen Rei- 
henfolge . 



Eine BlockgroSe bestimmt die Anzahl der Businessobjekte, 
die in einem Durchlauf bearbeitet werden. Der Extraktor 
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kann seriell arbeiten, also einen Durchlauf nach dem an- 
deren abarbeiten. Auch eine parallele Betriebsweise ist 
objektweise mdglich. 

Die Strukturen des OLTP-R/ 3 -Systems werden durch Mapping 
in Strukturen des MS-Systems uberfuhrt. Das Mapping wird 
feldweise durchgef uhrt . Dabei konnen Felder zu einem Feld 
verkettet oder ein Feld in mehrere Teile unterteilt wer- 
den. Die Feldtypen werden konvertiert. Da ruber hinaus 
wird abhangige Information aus den Quellfeldern erzeugt. 

Der Schlusselgenerator KG dient dazu, zu den OLTP-R/3- 
Schlusseln jeweils CRM-MS -Schlussel zu finden. Dabei wird 
jeweils ein Schlusselgenerator spezifisch fur einen Typ 
von BDocs unter Benutzung von Repository- Information ge- 
neriert . Urn den Schlusselgenerator-Agenten aktuell zu 
halten, ist ein Generator zur Erzeugung von Schlusselge- 
neratoren bei dem Generatoragenten des Repository als 
Abonnent registriert, um aufgerufen zu werden, wenn sich 
die entsprechende Information des Repository andert . 

Der Schlusselgenerator empfangt ein BDoc und setzt fur 
alle vorhandenen OLTP-R/3 -Schlussel CRM-MS -Schlussel , 
hier in Form von GUIDs (globally unique identifiers) , 
ein. Die erf orderlichen MS-Schlussel werden an ver- 
schiedenen Stellen gesucht, namlich zunachst in einer lo- 
kalen Tabelle des Schlusselgenerators , dann uber eine 
Schlussel -Mapping -Tabelle und schlieSlich in der konsoli- 
dierten Datenbank CD. Wenn kein MS-Schlussel gefunden 
wird; wird ein neuer erzeugt und in die verschiedenen 
Mapping-Tabellen eingef iigt . 

Die zusatzliche Schlussel -Mapping -Tabelle ist notwendig, 
um in den Fallen, in denen die Daten noch nicht in der 
konsolidierten Datenbank CD abgespeichert sind, die 
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doppelte Erzeugung eines Schlussels zu verhindern. Die 
lokale Tabelle des Schlusselgenerators ist optional und 
dient lediglich dazu, als Cache die Performance zu ver- 
bessem. 

2ur Synchronisation zwischen der OLTP-R/3 Datenbank OLTP- 
DB und der konsolidierten Datenbank CD des MS-Systems 
sind zwei Komponenten vorgesehen: "Request" und 
"Compare", die Request -Komponente ist sehr ahnlich wie 
die Komponente fur die Erstdatenbefullung. Sie ermoglicht 
es, gezielt bestimmte Businessobjekte aus der OLTP-R/3 
Datenbank OLTP-DB in die konsolidierte Datenbank CD her- 
unterzuladen und damit die Replikation^ der Dafeen^der 
tragbaren Rechner MC (unter Kontrolle -de<&- FluSsteuerung 

FC)., durchzufuhren. Die von einem Request spezif izierten 

Filterkriterien ,werden mit den allgemeinen Filterkrite- 
rien der Erst da t enbe full ung gemi s cht 7 so ~da£ nur,.eine Un- 
termenge-der wahrend der Erstdatenbefullung verarbeiteten 
Daten ausgewahlt werden kann. Die Request -Komponente kann 
sowohl interaktiv als auch im Batch-Modus gestartet wer- 
den. 

Die Compare -Komponente ladt Business-Daten aus dem OLTP- 
R/3 -System herunter. Die Unterschiede, die aus dem Ver- 
gleichsvorgang resultieren, beschreiben die Anderungen, 
die in der konsolidierten Datenbank CD vorgenommen werden 
mussen, damit ihr Inhalt mit dem Inhalt der OLTP-R/3 Da- 
tenbank OLTP-DB. ubereinstimmt . Dabei wird die Anderungs- 
information ("Insert", "Update", "Delete") in BDoc-Struk- 
turen ge spei chert . Nach dem eigentlichen -Vergleichsvor- 
gang werden die Anderungen auf die konsolidierte Daten- 
bank DB angewandt, urn sie konsistent mit der OLTP-DB zu 
machen. Aus der Anderungs information werden BDocs erzeugt 
und zur Replikation der lokalen Datenbanken LD der 
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mobilen Klienten MC (kontrolliert durch die FluSsteue- 
rung) verwendet . 

Nachfolgend werden einige fur die Erfindung wesentliche 
Funktionen erganzend erlautert. 

1. Systemubergreif ende Bereitstellung von Primarschlus- 
seln 

Wie oben dargelegt, ist es fur die semantische Integra- 
tion of f line-verteilter Datenbanksysteme wesentlich, dafi 
systemubergreif end ein Primarschlussel zur Verfugung 
stent, der eine eindeutige Identif ikation der Datenob- 
jekte uber die Grenzen der miteinander verschmol zenen Da- 
tenbanksysteme hinaus ermoglicht. 

Die Grundprinzipien einer hierzu geeigneten Verfahrens- 
weise sind (erganzend zu den oben bereits gegebenen Er- 
lauterungen) in Figur 8 dargestellt. Der Schlusselgenera- 
tor KG erhalt die in einem der hier allgemein mit A bzw. 
B bezeichneten Datenbanksysteme (Ursprungsystem) erfaSten 
Daten. Dazu gehort der jeweilige systemspezif ische Pri- 
marschlussel K A bzw. K B - Fur den jeweils anderen Pri- 
marschlussel (des Zielsystems) ist in dem Datensatz ein 
leeres Feld vorgesehen. Der Schlusselgenerator liest den 
Inhalt einer Schlussel- Mapping -Tabelle (Key Mapping 
Table) KMT und vergleicht mit den Schlusself eldern des 
von einem der Systeme A oder B angelief erten Datensatzes. 
Falls der Primarschlussel des Ur sprung systems (beispiels- 
weise K A ) in der Schlussel -Mapping-Tabelle KMT bereits 
vorhanden ist, betrifft der angel ieferte Datensatz eine 
Anderung (Update) eines bereits exist ierenden Eintrages . 
In diesem Fall wird der zugehdrige Primarschlussel des 
Zielsystems (beispielsweise K B ) aus der Schlussel - 
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Mapping-Tabelle KMT gelesen und in das leere Feld des 
Datensatzes eingetragen. 

Wird hingegen der angelief erte Primarschlussel in der 
Schlussel-Mapping-Tabelle KMT nicht gefunden, so handelt 
es sich urn die Neuanlage (Insert) eines Datensatzes. In 
diesem Fall wird von einem Schlusselerzeugungsmodul (Key- 
Generate Module) KGM der fehlende Primarschlussel (bei- 
spielsweise Kg) erzeugt und in die Schlussel-Mapping- 
Tabelle KMT geschrieben. Aufierdem wird er in das leere 
Datenfeld eingetragen. Danach ist der Datensatz auch in 
dem Zielsystem eindeutig identif izierbar und die Schlus- 
sel des Ursprungsys terns und des^Ziel systems* si*nd einander 
eindeutig zugeordnet . 

Eih prakt ischercWeg zur Dur chf uhrung x di e s e s Prinzips bei 
einem Da tembanfcsy stem^ dessen*Datienob*j?ekt(e v wi«e die oben 
beschriebenen "BDocs - in der prakt^ischen^Imp^*ementierung 
eine komplizierte Struktur hierarchisch gegliederter Da- 
tensegmente .enthalt en, wird nachfolgend erlautert . 

In Figur 9 ist eine sehr einfache Struktur bestehend aus 
zwei Segmenten SI und S2 dargestellt. Das Segment SI ist 
dem Segment S2 hierarchisch urn eine Stufe ubergeordnet 
und wird deshalb als Vatersegment zu dem Kindsegment S2 
bezeichnet. Das Vatersegment ist im dargestellten Fall 
das Root -Segment des BDoc. 

Das Vatersegment SI enthalt einen PrimarsohlusseKK^g des 
MS-Systems und einen Primarschlussel K R / 3 des^OLTP-R/3- 
Systems.* Jeder der Schlussel ist *in^einem oder mehreren 
Feldern des Segments abgespeichert . 

Auch das Kindsegment enthalt einen (in einem Feld abge- 
speicherten) Primarschlussel Kj^g des MS-Systems und einen 
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(in drei Felder abgespeicherten) Schlussel K R y 3 des OLTP- 
R/3-Systems . AuSerdem sind in den Feldern des Kindsegmen- 
tes auch die Schlussel des ubergeordneten Vat er segment es 
enthalten, wie durch die Pfeile zwischen beiden Segmenten 
verdeutlicht wird. Diese Felder haben jedoch keine 
Schlusselfunktion, sondern dienen als sogenannte Foreign- 
Keys zur Information uber die Segmentstruktur . Sie zeigen 
also an, dafi S2 ein Kind des Segmentes SI ist. 

In Figur 9 rechts ist eine zugehorige Schlussel -Mapping - 
Tabelle dargestellt, wobei in den mit den Pfeilen be- 
zeichneten Zeilen die Schlussel der Segmente SI und S2 
verzeichnet sind. 

Figur 10 zeigt eine etwas komplexere Feldstruktur mit ei- 
nem Vatersegment SI (Root -Segment des BDoc) , zwei hierar- 
chisch untergeordneten Segmenten S2a und S2b der Kindge- 
neration und einem Segment S3 der Enkelgeneration, das 
ein Kind des Segments S2 ist. Beispielsweise kdnnte das 
Segment SI fur ein BDoc des Typs "Kunde" Name und Adresse 
des Kunden, das Segment S2a die Ansprechpartner bei dem 
Kunden, das Feld S3 Kont aktinf ormati onen der Ansprech- 
partner (Telef onnummern, Dienstzeit etc.) und das Feld 
S2b Inf ormationen uber bei dem Kunden install ierte Ma- 
schinen enthalten. 

Auch in diesem Fall enthalt j edes Segment (im dargestell- 
ten Fall der Ubersichtlichkeit halber nur jeweils in ei- 
nem Feld) die Schlussel Kj^g und K R /^ beider Datenbanksy- 
steme, wobei die abhangigen Systeme jeweils die Schlussel 
der Vatergeneration als Foreign-Keys enthalten. Die auf 
der rechten Seite der Figur 10 dargestellte Schlussel - 
Mapping -Tabelle zeigt wiederum die Zuordnung- der Schlus- 
sel beider Systeme . 
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In der Praxis konnen Datenobjekte grofier Datenbanksysteme 
sehr komplizierte Strukturen mat zahlreichen ineinander 
verschachtelten Hierarchieebenen haben, wobei die Seg- 
mente oft sehr groSe Zahlen von Daten-Records enthalten. 
Hinzu kommt, dafi haufig spezielle Struktur el entente erfor- 
derlich sind, um besonderen Anforderungen Rechnung zu 
tragen. Beispielsweise besteht haufig das Bedurfnis, auf 
Daten einzelner Daten-Records rasch zugreifen zu konnen, 
obwohl sie sich in unteren Hierarchieebenen befinden. In 
diesen Fallen ist es zweckmaSig, den bendtigten Schlussel 
eines hierarchisch tieferen Segments in einem speziellen 
Feld eines hoheren Segments abzuspeichern. Beispielsweise 
ist in Figur 10 dargestellt r dander. Sch*lussel> mit dem 
Code C1 M des *ersten Daten - Records ^des. Segment es S2a in 
dem^Spezialfel-d^SF^-des,, Segment es *S1 ^eingetragen < ist , bei- 
spielsweise um - einen d^rekfeen^Zu^grif f^auf^den^wicht igsten 
AnsprechpartneB^des^in SI codvieKten^Kunden^zu^ermogli- 
chen. Durch solche strukturellen*»Be H sonderheiten wird die 
Durchfuhrung des oben geschilderten* Verf ahrens in der 
Praxis sehr* schwierig. 



Derartige Probleme konnen mit dem nachfolgend dargestell- 
ten Algorithmus gelost werden. Er besteht aus zwei Pro- 
grammteilen, die mit PASS-I und PASS-II bezeichnet sind. 
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PASS-I: 

Fur alle (def inierten) Segmente { 
Fur alle Datensatze { 
// Fulle Kj^s // 
Falls (Kj.jg = LEER) { 

Suche in KMT (K R / 3 ) 
Falls Eintrag vorhanden { 
Entnehme K^q aus KMT 
Eintrag K^q in BDoc 
} andernfalls { 

Generiere neuen 

Eintrag K R / 3 , K^ in KMT 

Eintrag K^ in BDoc 

} 

} 

// Fulle MS Father Key // 

Falls (MS Father Key = LEER) { 

Positioniere in BDoc -Father- Segment (R/3 
Father Key) 

Entnehme MS Father Key aus BDoc-Father- 
Segment 

Eintrag MS Father Key in BDoc 

} 

} 

} 

In PASS-I wird fur alle def inierten Segmente (d.h. fur 
alle Segmente, fur die eine Schlusselgenerierung benotigt 
wird) und fur alle Datensatze der mit dem Kommentar 
"Fulle MS -Primary -Key 11 uberschriebene Teilalgorithmus 
durchgef uhrt . In diesem Teilalgorithmus wird zunachst ab- 
gefragt, ob das Feld des Primarschlussels leer ist . Falls 
dies zutrifft, wird in der Schlussel-Mapping-Tabelle un- 
ter dem vorhandenen Schliissel K R y 3 gesucht, ob ein Ein- 
trag vorhanden ist. Gegebenenf alls wird der zugehdrige 



MS-Primarschlussel aus der Schlussel-Mapping-Tabelle ent- 
nommen und in das BDoc eingetragen. 



Falls kein Eintrag des gesuchten K R/3 vorhanden ist, wird 
ein GUID als neuer MS-Primarschlussel erzeugt und, sowohl 
der K R/3 als auch der wird in die Schlussel-Mapping- 

Tabelle eingetragen. AuSerdem erfolgt ein Eintrag des K^ s 
in dem BDoc . 

Weiter wird der mit dem Kommentar "Fulle MS -Father- Key" 
uberschriebene Teilalgorithmus durchgef uhrt . Falls das 
Feld fur den MS-Vater-Schlussel leer ist, wird die Lese- 
position* in das*. Vat er segment innerha*bb-deswBDoc gebracht 
und -zwar in den Dat en -.Record^ der • den .enfcspreehenden K R/3 
enthalt .... Dann -wird^der entsprechende- ? ^g ^aus ^dem Vater- 
segment entnpmmenrund ^in^das^Foreian^Key-.E^id^des Kind- 
s egmenfce;sj*e i*ngeter agen? . 

Der PASS -I wird mehrfach durchgef uhrt , bis alle Segmente 
des BDoc in der durch die Hierarchie vorgegebenen Reihen- 
folge (beginnend mit der hochsten Hierarchieebene) abge- 
arbeitet sind. 

Danach wird PASS-II gestartet . Er wird uber eine in dem 
Repository gespeicherte Tabelle, die als FETCH - Tabe lie 
bezeichnet wird, gesteuert . Darin sind Auf f ullaktionen 
beschrieben, die in dem PASS-I nicht mdglich sind. Hierzu 
gehoren das Auffullen mit Werten aus hierarchisch niedri- 
gerenr Segment en (wie- in Figur-10 dargesfeelrl,t.)^ und das, 
Auf full en* mit Schlusseln aus einer Hierarchieebene, di?e 
hoher ist als die Vaterebene (also beispielsweise zwei 
Ebenen hoher, d.h. GroSvater) . 



Urn diese Funktionen erfullen zu konnen, 'hat die FETCH-Ta- 
belle folgenden Aufbau: 

• DestTbl : Destination Table 

• DestFld: Destination Field 
- SrcTbl: Source Table 

• SrcFld: Source Field 

• Cond: k r/3 oc^r Bedingung nach dem Muster x = y 

Ein Eintrag in der FETCH - Tabe lie erzeugt eine Auffull- 
aktion aus dem Quellfeld der Quelltabelle in das als 
Zieltabelle bezeichnete Segment eines BDocs . 

Algorithmusdarstellung des PASS-II: 

Fur alle definierten Segmente { 

Fur alle Eintrage in der FETCH-Table . in denen 

DestTbl = Segment { 

Lese Werte aus FETCH-Table ein 

Falls (Cond = R/3) { 

// Werte innerhalb des BDocs 

p Posit ioniere im BDoc auf SrcTbl (K R ^ 3 ) 

Schreibe SrcTbl -> SrcFld in DestTbl -> 
DestFld 

} andernfalls { 

// Werte aus CD 

Positioniere in CD auf SrcTbl mit Filter = 
Cond 

Schreibe CDSrcTbl -> SrcFld in DestTbl -> 
DestFld 



Fur alle Segmente des bearbeiteten BDoc und fur alle Ein- 
trage in der FETCH- Tabe lie, fur die das Segment als 
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DestTbl eingetragen ist, wird der Wert aus der FETCH-Ta- 
belle gelesen. Danach erfolgt eine Fallunterscheidung. 
Fur den Fall, dafrCond = R/3 gesefc,zt ist, handelt es sich 
urn eine Ubertragung von Schlusselwerten innerhalb des 
BDocs, wobei der Inhalt des Quellfeldes in dem Quellseg- 
ment ubertragen wird in das Zielfeld innerhalb des Ziel- 
segraentes. Falls die Bedingung Cond einen anderen Wert 
hat, werden Werte aus dem BDoc selbst oder aus der konso- 
lidierten Datenbank CD ubernommen, wobei im letzteren 
Fall auf eine Quelltabelle innerhalb der Datenbank CD zu- 
griffen und deren Inhalt in das Zielfeld des Zielsegmen- 
tes ubertragen wird. 

2. Data-Mer,ge> 

Ein we i t e r e s igrunda egende s' *Pr ob lem^ be i de^Verschmelzung 
unterschiedl ichea^DaterLbanks^ dafi die 

zu einom bcotimmf on--Typ von Dat e nobj e kt e n^in^boid e n Syr 



stemen vorhandenen Da ten unterschiedlich sind. Beispiels- 
weise konnen zu dem Datenobjekt "Kunde" in einem CRM-Sy- 
stem Inf ormationen uber einzelne Kundenkontakte oder vor- 
bereitende Verkauf sgesprache ("Opportunities") enthalten 
sein, die von einem ERP-System nicht benotigt werden. Um- 
gekehrt enthalt das Datenobjekt "Kunde" in einem ERP-Sy- 
stem In format ionen, wie beispielsweise das vollstandige 
Kundenkonto seit Beginn der Geschaf tsbeziehungen, die von 
dem CRM-System nicht benotigt werden und fur die demzu- 
folge in den dort bearbeiteten Datenob j ekten keine Seg- 
ment e »vorhanden sind. 

Hinsichtlich der Primarschlussel ist die vorstehend er- 
lauterte Logik vorteilhaft, bei der in einem der Systeme, 
namlich dem Front -of f ice-System MS beide Schlussel 
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und K R ^3 der miteinander verschmolzenen Systeme vorgehal- 
ten werden, wahrend in dem Back-off ice-System nur dessen 
Schlussel K R ^ 3 vorgehalten wird. 

Urn in einer derartigen Konstellation einen moglichst 
vollstandigen Austausch von Daten zu ermoglichen, wird 
bevorzugt ein " Data -Merge -Verfahren" eingesetzt, das un- 
ter Verwendung folgender Konvention anhand der Figuren 5 
und 11 beschriebenen wird: 

Dj^g: Daten, die nur in dem MS-System existieren 

D R/3 : Daten, die nur in dem OLTP-R/ 3 -System existieren 

D Mix : Daten, die in beiden System existieren 

Wenn Daten, wie in Figur 11 dargestellt, aus dem MS-Sy- 
stem als systemspezif isches Datenobjekt (BDoc) zur Uber- 
mittlung an das OLTP-R/3 -System bereitgestellt werden, 

enthalten sie D MS , — D Mix und K^ s als Schlussel . — in dem 

OLTP-Adapter OLTP-AD werden die Daten D MS von dem BAPI- 
Caller BC herausgeteilt und geparkt . Danach transportiert 
der OLTP-Adapter die restlichen Informationen °Mi x und 
Kj^g in das OLTP-R/3 -System. Der Schlussel des Ursprungsy- 
stems Kj^g "wird in dem Ziel system OLTP-R/3 abgetrennt und 
in dem Speicherbereich Erganzungsdaten AMD geparkt. 

AnschlieSend werden die -Daten mit Erganzungsdaten D D 
erganzt f die notwendig sind, urn das entstandene Datenob- 
jekt in dem Zielsystem (OLTP-R/3) zu bearbeiten. Diese 
Erganzungsdaten sind in der Regel Voreinstellungswerte 
(Def aultwerte) fur die entsprechenden Datenf elder. 

Danach wird die normale . Bearbeitung in dem OLTP-R/3-Sy- 
stem durchgef uhrt . Die Daten werden asynchron mit der in 
dem Zielsystem gebrauchlichen Verbuchungsroutine gepruft 
und in der Datenbank OLTP-DB abgespeichert . 
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In Verbindung mit der Verbuchung wird ein Event ausge- 
lost, das von dem Eventdistributor ED unter anderem an 
den Ergebnisubermittler RS ubermittelt wird, der darauf- 
hin die Daten aus der Verbuchung ubernimmt. Das erhaltene 
Datenpaket besteht aus D R / 3 , D Mix und K R ^ 3 . Der Ergebnis- 
ubermittler RS fugt den geparkten MS-Schlussel K,^ ein 
und entfernt die fur das MS-System nicht relevanten Daten 
D R/3* Danacn erfolgt die Ubergabe in das MS-System als 
Datenpaket D M±X , und K R / 3 . Innerhalb des MS-Systems 

werden von dem Ergebnis- Save -Agent en RSA die geparkten 
Daten D^ wieder angefugt, so dafi das vollstandige BDoc 
mit den Daten E^g, ^ix' %S und K R/3 zur Weiterverarbei- 
tung (insbesondere zur Konsolidierung in der^ Datenbank CD 
und - zur anschliefienden Replikation an die mobilen Klien- 
ten MC )" . zur f .Ver f ugung stent . 

Dieses Da fea -Merge -Verf ahren* f inde.fembei- j edem Update von 
Dat e n au s .^d e m-^M S * System in dao; OLTP ■ R/3 - Sy s t e m jgtatt . B e i 
Datenanderungen in dem OLTP -R/3 -System (Del^tadownload) 
lauft ein Teil dieses Verfahrens beginnend mit der Verbu- 
chungsroutine ab, wobei selbstverstandlich kein MS- 
Schlussel Kjyjg hinzugefugt werden kann. Er wird in diesem 
Fall von dem Schlusselgenerator KG in der oben erlauter- 
ten Weise generiert . 

3 . Download 

Ein wesentliches Ziel der Verschmelzung von Datenbanksy- 
steraen besteht- darin, gemeinsam. benutzte Daten^in.den Sy- 
stemen nicht getrennt pf legen zu mussen, sondea=n die in 
den miteinander verschmolzenen Datenbanksystemen vorlie- 
genden Daten gemeinsam nutzbar zu machen. Beispielsweise 
soil ein CRM-Front-off ice -System auf Daten uber Kunden- 
und Produktinf ormationen zugreifen konnen, die in dem 
ERP-Back-off ice-System des Unternehmens gespeichert sind. 



a) Erst da tenbeful lung 



Damit stellt sich zunachst die Aufgabe, diejenigen Daten 
eines bereits bestehenden ersten Da tenbanksys terns (Ur- 
sprungsystem A, hier OLTP-R/3 -System) , die auch von einem 
neu implementierten weiteren Da tenbanksys tern (Zielsystem 
B, hier MS -System) benotigt werden, im Rahmen einer Erst- 
datenbefullung (Initial Download) von dem System A an das 
System B zu ubertragen. In diesem Zusammenhang werden im 
Rahmen der vorliegenden Erf indung folgende Problemlosun- 
gen vorgeschlagen. 

Die Datenmengen in dem vorhandenen Back-off ice -System 
(nachfolgend weiterhin ohne Beschrankung der Allgemein- 
heit als OLTP-R/3 -System bezeichnet) sind in der Regel 
sehr groS. Deswegen mussen Mittel bereitgestellt werden, 
die mit anderen Systemen auszutauschenden Daten naher zu 
apezilizi eren" Im Rahmen der t;rf mdung ertolgt dies vor- 
zugsweise durch Filterung. 

Fur die Filterung werden die im Zusammenhang mit Figur 7 
beschriebenen Extraktoren verwendet, die von dem OLTP- 
R/3 -System zur Verfiigung gestellt werden. Eine Besonder- 
heit besteht dabei darin, daZ in Form der Extraktor-Ma- 
sters eine standardisierte Schnittstelle zu dem MS-System 
verwendet wird, uber die alle Anfragen des MS -Systems 
laufen. Die Daten werden also dadurch gefiltert, dafi das 
Zi el -Da tenbanksys terns MS die Anf orderungen fur von ihm 
bendtigte Daten uber eine standardisierte Schnittstelle 
an Extraktoren ubertragt, die in dem Ursprungs system 
OLTP-R/3 implementiert sind. 

Ein weiteres Problem besteht darin, die Erstdatenbef ul - 
lung in einer vertretbareh Zeit zu ermoglichen. Dies ist 
mit den ublicherweise in Back-off ice -Systemen vorhandenen 



Mitteln nicht moglich, weil diese fur die rasche Ubertra- 
gung sehr grpSer Datenmengen nicht eingerichtet sind. 
Dieses Problenwwird im Rahmen der Erf indung vorzugsweise 
dadurch gelost, dafi die oben naher erlauterten als mas- 
senorientierte BDocs bezeichneten speziellen Datencontai- 
ner zur Verfugung gestellt werden. 

SchlieSlich besteht ein Problem der Erstdatenbefullung 
darin, sicherzustellen, dafi die an das Ziel-Datenbanksy- 
stem ubertragenen Daten einem ganz bestimmten Zustand des 
Ursprungsdatenbanksystems zu einem definierten Zeitpunkt 
(Snapshot) entsprechen. Herkommlich wird dieses Problem 
gelost , indenv man das Ursprungs-Dateribariksyjsfcem* wahrend 
der Erstdafcenbef u*llungi^fur' Anderungen spe^rt^oder so- 
weit Ande-ramge^n^zuge^assen^sind*^- spezielle ^Iristrumente 
der Ursprungs^Da^feenba-nk nut.zt,^. die**j edoch^e ine^Da t enbank- 
unabhangige Operateiona^ita^ aus- 
sclilie£ei-K • — ; — 

Zur Losung dieses Teilproblems wird im Rahmen der Erfin- 
dung ein Verfahren vorgeschlagen, welches nachfolgend als 
Onl ine - Synch -Verfahr en bezeichnet und anhand von Figur 12 
erlautert wird. Dabei arbeiten die in "dem Ursprungs system 
OLTP-R/3 implementierten Extraktoren, die - gesteuert 
durch in dem Zielsystem MS gespeicherte Filterdef inition 
FD - uber die Extraktor-Master-Schnittstelle EM angespro- 
chen werden, normal in Blocken lesend und abgebend, wobei 
sie die dynamische Datenanderung der Ursprungsdatenbank 
ignorieren** Die- Masse der von dem ZieLsysfcem«*bendtigten 
Daten wird daimit au-f* dem durch den Pfeil IL (Initial* 
Load) bezeichneten Weg ubertragen. 

Parallel lauft jedoch auch das bereits erlauterte Delta- 
Handling mittels des Ergebnisubermit tiers RS ab. Dadurch 
werden Anderungen, die in dem Ur sprung system wahrend der 
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Erstdatenbefullung anf alien, in eine queue Q eingestellt. 
Im Gegensatz zum normalen Deltadownload-Betrieb wird 
diese queue jedoch nicht freigegeben, sondern wahrend der 
Dauer der Erstdatenbefullung gesperrt (Queue-Stop QS) . 
Nach Beendigung der Erstdatenbefullung wird die Ande- 
rungsqueue freigegeben und die wahrend der Erstdatenbe- 
fullung durchgefuhrten Anderungen werden uber den durch 
den Pfeil DL (Deltaload) symbolisierten Deltadownload-Ka- 
nal an das Zielsystem MS ubertragen. Somit entsteht ein 
konsistenter "Snapshot", bezogen auf den Zeitpunkt der 
Beendigung der Erstdatenbefullung. 

b ) De 1 1 ado wnl oad 

Auch hinsichtlich der Funktion Deltadownload wird auf die 
weiter oben (vor allem anhand von Figur 5) und zu dem 
Data -Merge -Verfahren gegebenen Erlauterungen Bezug genom- 
men. Es geht dabei darum, nach der Erstdatenbefullung im 
laufenden Betrieb alle an ein Ursprungs-Datenbanksystem A 
angeschlossenen Systeme jeweils mit Anderungen zu versor- 
gen. 

Die Funktion wird in zwei Teilschritten bereitgestellt : 

a) Mitteilung des Ur sprung s - Da tenbanksys terns uber durch- 
gefuhrte Anderungen und 

b) Aufgreifen der Anderung und Aufbereitung sowie an- 
schlieSende Ubergabe an das Zi el -Da tenbanksys tern zur 
Wei terverarbeitung . 

Ublicherweise werden zur Mitteilung uber durchgefuhrte 
Anderungen Anderungspo inter verwendet . Dies hat jedoch 
erhebliche Nachteile. Zum einen ist es erf orderlich, in 
der Applikation des Ursprungs-Datenbanksys terns fur jede 
mogliche Anderung einen Anderungspo inter vorzusehen. Dies 
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ist meist nicht fur alle Datenobjekte moglich, zumindest 
aber sehr aufwendig und eine Icritische Fehlerursache . Zum 
zwei-ten f indet die Ubermittlung von Anderungen* nur- in 
vorgegebenen Zeitintervallen statt. 

Zur Losung dieses Teilproblems wird im Rahmen der Erf in- 
dung vorzugsweise die Event-Technik benutzt. In die Rou- 
tine zur Einarbeitung einer Anderung in die Datenbank 
OLTP-DB des Ursprung-Datenbanksys terns ist die Erzeugung 
eines Events integriert . Uber den Event -Distributor ED 
werden Funktionsbausteine, die eine Subskription fur das 
Event unterhalten, bei Eintreten des Events aufgerufen. 
Zu diesenr Funktionsbausfeeinen^gehort- ein entsprechender 
Baustein des Ziel*-Datenbanksys terns (in Figur 5 eine Kom- 
ponente ; xdes^Ergebni'S -jSa-^e -Agenten*RSA) v. Sdmrt^bekommt der 
OI/TP-^/^ Ada£^r^des#M^ gesprochen 
al so&ei*n Bausfcei*^ 'des^Ziel*systsems'k zea*t nah^eirae .inf orma - 
t i on i n dem#t7r sprungst-5Da feenbanksy s fe em * 

Die anschlieSende Ubertragung der Anderung von dem Ur- 
sprungs - Da t enbanksy s t em an das Ziel - Da t enbanksy stem er- 
folgt anhand der bereits diskutierten in dem Ziel-Daten- 
banksystem gespeicherten Filterkriterien FD (Figur 12) . 
Danach werden die Daten mit Hilfe des oben beschriebenen 
Data-Merge-Verf ahrens aufbereitet und es wird mit der 
ebenfalls weiter oben beschriebenen Verf ahrens we ise ein 
systemubergrei fender Primarschlussel generiert . 

Eine weitere-Besonderheit der Datenubermittlung besteht 
dar i n # * da& * ( i nsbe s onde re be i dem De 1 1 ado wnl o ad ) die na oh - 
folgend beschriebene Netto-Feld-Ermittlung verwendet 
wird. 

Um das gegenseitige Uberschreiben von Anderungen, die 
durch viele unabhangig auf die gleichen Datenbestande 
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zugreifende Benutzer durchgefuhrt werden, zu minimi eren, 
ist es vorteilhaft, nur die geanderten Felder der jewei- 
ligen Datensatze zu ubertragen. Dies wird als Netto-Feld- 
Ubertragung bezeichnet. ERP-Back-of f ice- Syst erne wie ins- 
besondere das OLTP-R/ 3 -System konnen in der Regel jedoch 
nur "Brutto-Feld" kommunizieren, d.h. sie ubertragen nur 
gesamte Datensatze mit samt lichen Feldinhalten auf ein- 
mal. Die Daten treten deswegen Brutto-Feld uber den Da- 
tenkanal DL (Figur 12) in das Zielsystem MS uber, wenn 
ein solcher Ubertritt durch den Ergebnisubermittler RS 
ausgeldst wurde. Dieser Nachteil wird gemafi einer bevor- 
zugten Ausf uhrungsf orm der Erfindung dadurch ausgegli- 
chen, dafi in dem Zielsystem, namlich dem Datenbankservice 
CDS der konsolidierten Datenbank CD die wirklichen Ande- 
rungen auf Feldebene durch Vergleich mit dem Inhalt der 
konsolidierten Datenbank CD ermittelt werden und nur die 
tatsachlichen Anderungen Netto-Feld in die Folgeverarbei- 
tung eingehen. 

Wie dies im einzelnen geschieht, wird anhand der Figuren 
13 und 14 erlautert. 

Zur Unterstutzung der Netto-Feld-Ubertragung ist in alle 
Segmente der BDocs (d.h. der Datenobjekte des Ziel-Daten- 
banksystems) ein Feld eingefugt, das die geanderten Fel- 
der wiederspiegelt . Dieses Feld wird als Send-Bit -Feld 
SBF bezeichnet. Es kann bei spiel sweise vom Typ RAW (32) 
sein- und beinhaltet in der Binardarstellung (zweckmaSi- 
gerweise als HEX abgelegt) an jeder Position eine "1", 
die mit einem Feld korrespondiert , welches eine Anderung 
erfahren hat. Diese Zuordnung der Send-Bit-Inf ormation 
SBF zu der Feldinf ormation FIN ist in Figur 13 graphisch 
dargestellt. Auch Loschungen werden als Anderungen ange- 
zeigt . In dem dargestellten Fall wurde beispielsweise der 
Feldinhalt der Felder 1 und 4 geandert (in "A" und "C") 
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und der Feldinhalt der Felder 2 und 8 geldscht. Der Feld- 
inhalt des zusatzliches Feldes SBF besteht aus einem re- 
levzari't-en Teil R, dessen Bit-Zahl der Zahl der Felder ent- 
spgpicht und einem nicht relevant en Teil L, der ignoriert 
wird. 

Fur den Fall, daS Datensatze Brutto-Feld in das Ziel-Da- 
tenbanksystem ubertreten, erfolgt ein Abgleich mit der 
Datenbank CD des Ziel - Da tenbanksys terns MS. Dieser Ab- 
gleich wird in dem Datenbankservice CDS der Datenbank CD 
durchgefuhrt und ist in Figur 14 graphisch dargestellt. 
Darin ist der Datensatz Dl ein Beispiel fur einen Brutto- 
Feld 'ubert rage neh Datensatz mit einem^geanderten Feldin- 
halt "X" . Der DatenbankservvicenCDS; vervglved-chfe-^den Daten- 
satz - mit dem^enfespr^eGhenden^in ^der :: DatenJ^ank^GD' ; abgeleg- 
ten^Datensatz^pl* 1 undgste;>l;t^f e>>t^ da^^nur^das^FeiLd mit 
demaaliihal^tA/'X^ Entesp^ejehein^ Da- 

tensatz D2^gene r i e r t , de^nur die geanderit ejliiforma t i on 
enthalt . Das? entspreehende^Send^Bi^t wu-rdev.auf ,J * n 1 " ge- 
sefe*zt-t Die ubrigen Feldinhalte wurden geleert . 

c) Synchronisation 

Semantische Integration in dem einleitend erlauterten 
Sinn bedeutet mehr als den reinen Austausch von Daten 
zwischen Systemen. Nach Moglichkeit soli sich das Appli- 
kationsverhalten hinsichtlich der grundlegenden Logik der 
Verarbei-tung der Nutzdaten ("Business Logik") annahern. 
Die** Business*- Logik spiegeit sich in, hohem* Mafie'fcin den 
Steuerdaten wider , die *in dem Repository des- jeweorligen 
Datenbanksys terns gespei chert sind und die Logik abbilden, 
wie beispielsweise Wertebereiche, Feld-, Satz- und Daten- 
bankplausibilitaten. Deswegen sollten im Rahmen der se- 
mantischen Integration auch die Repository- Steuerinf orma- 
tionen systemubergreif end repliziert werden. Im Falle des 





OLTP-R/3- Systems sind dies die sogenannten Customizing- 
Tabellen (T- tables) . Anderungen an den Customizing-Tabel- 
len werden in dem OLTP-R/3 -System jedoch weder durch An- 
demngs- Pointer noch als Events angezeigt . Demzufolge 
wird ein Replikat dieser Daten in einem Ziel-Datenbanksy- 
stem wie dem MS System schnell veralten, wenn kein ge- 
eigneter Aktualisierungsmechanismus zur Verf ugung steht . 

Urn auch in derartigen Fallen eine laufende Synchronisa- 
tion des Datenzustandes zwischen einem Ursprungs system 
und einem Ziel system zu ermoglichen, werden die bereits 
erwahnten Komponenten "Request" und "Compare" verwendet. 
Der damit realisierte Synchronisationsmechanismus wird 
anhand der Figuren 15 und 16 verdeutlicht . 

Die Komponente Request arbeitet wie bereits erlautert 
analog wie die Erstdatenbef ullung . Urn beliebige Business- 
objekte aus dem OLTP-R/3 -System in das MS-System herun- 
terzuladen wird ein Modul verwendet, der als General-Ex - 
traktor GE bezeichnet und entsprechend der Filterdef ini- 
tion FD uber den Extraktormaster EM angesprochen wird. 

Bevor die so heruntergeladenen Daten in die konsolidierte 
Datenbank CD eingearbeitet werden, wird der in Figur 15 
mit COMP bezeichnete Compare -Modul aufgerufen, der die 
heruntergeladenen Daten mit den bereits in der Datenbank 
CD exist ierenden Daten vergleicht und nur tatsachlich ge- 
anderte Daten passieren laSt. Aufierdem erzeugt er Losch- 
auftrage fur nicht mehr im Original vorhandene Daten. 

Der hierzu verwendete Algorithmus lafit sich anhand von 
Figur 16 verdeutlichen . In einem Vorbereitungslauf werden 
zunachst die aus dem OLTP-R/3 -System empfangenen Daten 
und die hierzu jeweils korrespondierende Tabelle aus der 
Datenbank CD in jeweils einem Speicherplatz S2 bzw. SI 
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bereitgestellt. Bei der Selektion der korrespondierenden 
Tabelle aus der Datenbank CD werden die Daten so gefil- 
tert, dafi alle Records, die nur in dem MS --System enthal- 
ten sind (in Figur 6 die Records ml und m2) , nicht in die 
Selektion fallen. Auch in den ubrigen Records sind Felder 
mit MS-spezifischen Daten enthalten. Durch eine weitere 
Restriktion bei der Datenubertragung wird dafur gesorgt, 
daS in dem Speicherbereich SI nur Daten bereitgestellt 
werden, die auch in dem OLTP-R/3- System verfugbar sind. 

Der anschlieSende Vergleich der Inhalte der Speicherbe- 
reiche SI und S2 erfolgt dadurch, daS eine der Tabellen 
als Referenz gewahlt wird, wobei, du-rch* dieses Tabelle von 
ihrem Beginn bi*s. zuiti: Ende$ ^ge steppfe** wi rd^und^in der ande- 
ren Tabe*l-le die^entspr^chenden, fEin^Trag^ge^iuchjt werden. 
Dabe i i s t=*t e s**aus**Pe &f dfetna$&cg^i3^^ dieje- 
nige Spe*eher^abei»I;e, ais^Re^f e'Benziizu^wamten^ d±e • die ge - 
ringere Anzahlv an^Eintragen, enthmt. (in* F%u2*16^die Ta- 
belle in dem- Sp^eicherbereifGh- SI) . In Abhangigkeit von dem 
Ergebnis des Vergleichs -werden entsprechende Aktionen 
eingeleitet wie: 

erzeuge Neueintrage: »i» 
erzeuge Netto-Feldeintrage : "U" 
erzeuge Lochauftrag: "D" 

Der Algorithmus laSt sich wie folgt darstellen: 
Fur alle Eintrage^in SI { 

Falls-vorhanden* in S2< { 




erzeuge Netto-Feld Eintrage ("U") 



} else 



erzeuge Loschauf trag ("D") 



• • 
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4 . Upload 

Wie dargelegt, ist es ein wesentliches Element der seman- 
tischen Integration von Datenbanksystemen, daS Datenauf- 
nahmen und -anderungen nicht nur in einem, sondern in 
mehreren oder alien der miteinander verbundenen Daten- 
banksysteme durchgefuhrt werden konnen. Beispielsweise 
soil es also moglich sein, dai5 AuSendienstmitarbeiter bei 
dem Kunden neue Daten (beispielsweise einen neuen Auf- 
trag) in ihren tragbaren Rechner eingeben und diese Ande- 
rung des Datenbestandes in der Datenbank OLTP-DB persi- 
stent gemacht wird. 

Anderungen auf der Ebene der mobilen Klienten werden 
durch die im Zusammenhang mit Figur 2 beschriebene Trans- 
aktionsschicht, uber die die mobilen Klienten mit dem MS- 
System und ihrer eigenen lokalen Datenbank LD kommunizie- 
ren, registriert. Wenn der tragbare Rechner mit dem Midd- 
leware-Server MS verbunden wird, werden die geanderten 
Daten als BDocs ubermittelt und auch an das Back-office- 
System OLTP-R/3 ubertragen. Die hierfur verwendeten Kom- 
ponenten wurden anhand von Figur 5 und das dabei ablau- 
fende Data -Merge -Verfahren wurde anhand von Figur 11 er- 
lautert . 

Eine wesentliche Anforderung bei einem solchen Daten- 
Upload ist die Entwicklung einer geeigneten Konfliktauf- 
losungsstrategie, urn Konflikte zwischen den an verschie- 
denen Orten aufgenommenen oder geanderten Daten zu ver- 
hindern. Die Definition von sogenannten "Datenpf legeho- 
heiten", die die Anderung von Daten jeweils nur an be- 
stimmten Stellen des Verbundsys terns gestattet, wiirde 
keine ausreichende Integration bieten. Auch das bei man- 
chen Anwendungen verwendete Verfahren LOW (Last One Wins) 
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ist fur ein derartiges Verbundsystem, das die Daten eines 
ERP-Back-off ice-Systems einschliefit , nicht geeignet. 

Deshalb wird im Rahmen der vorliegenden Erf indung- eine 
neuartige Konf liktlosungsstrategie verwendet, die als LSC 
(Leading System Concept) bezeichnet wird. Das LSC-Verfah- 
ren definiert fur jedes Datenobjekt ein fuhrendes System 
(FS) . Alle anderen Systeme des Verbundsys terns sind ge- 
fuhrte Systeme (GS) . Jede Anderung eines GS. mu£ erst 
durch das FS bestatigt werden. Ein wesentlicher Unter- 
schied gegenuber ublichen Bestatigungsfunktionen besteht 
darin, dafi es sich hier urn eine Funktion handelt, die Ap- 
plikationsgrenzen uberschreitet und dazu dient, Konflikte 
zwischen Systemen, deren Stukturen nicht kompatibel sind, 
zu losen. 

Die Implementierung des. LSC'-Verf ahrens erfordert spe- 
zielle Funktionen, die nachfolgend erlautert werden. 

In dem hier beschriebenen Beispiel ist fur. alle Datenob- 
jekte das MS-System das gefuhrte System. Das gefuhrte Sy- 
stem muS in der Lage sein, folgende Anf orderungen zu er- 
fu.ll en: 

Der Benutzer mu£ bei der Darstellung der Daten jeder- 
zeit deren Bestatigungsstatus (akzeptiert, abgelehnt , 
of fen) erkennen konnen. 

Der Benutzer muS bei Ablehnung der von ihm geanderten 
Daten wieder auf seine ursprunglichen Werte zugreifen 
konnen . 

Das Datenobjekt darf nicht gesperrt sein, bis eine An- 
derung. bestatigt ist, d.h. es mu6 moglich sein, da£ 
mehrere zu prufende Anderungen an dem gleichen Daten- 
objekt aufeinander folgen, ohne dafi das Ende der vor- 
herigen Prufung abgewartet werden muB. 
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Die Datenkonsistenz im gesamten Systemverbund muS ge- 
wahrleistet sein. 

Die Erfullung dieser Anf orderungen wird vor allem durch 
zwei Funktionsmodule mdglich, die als Pending Counter 
(PC) und als Inbox (IB) bezeichnet werden. 

Der Pending Counter ist sin Char(4)Feld, das sich in ie- 
der an dem Datenaustausch beteiligten Tabelle (also in 
jedem Segment der BDocs) befindet. Uber dieses Feld ist 
der aktuelle Bestatigungszustand der Daten definiert. Es 
bildet Win Control 1 -Flag, das von dem Anwendungsprogramm 
ausgewertet wird, urn den Bestatigungszustand der Daten - 
beispielsweise auf dem Bildschirm - zu visualisieren. 



Der Pending Counter hat folgende Auspragungen : 
"O" : OK 

P<n>: Pending (= of fen, noch nicht bestatigt) 

wobei <n> als Ref erenzz.ahler die Anzahl der 
Anderungungen hochzahlt 

F<n> : Datensatz ist im Fehlerzustand 

1 Der Pending Counter wird bei jeder Anderung hochgezahlt • 

und bei Bestatigung durch das fuhrende System wieder her- 
untergezahlt , bis er wieder auf "0" steht - Im Falle der 
Ablehnung wird ebenfalls heruntergezahlt, jedoch anstelle 
eines "P" eine "F" gesetzt. 



Urn die Datenkonsistenz im Gesamtsystem zu gewahrleisten, 
ist es notwendig, da£ bei nicht akzeptierten Anderungen 
der ursprungliche Datenzustand in dem gefuhrten System 
wiederhergestellt wird (Roll Back) . Dies geschieht ' vor- 
zugsweise dadurch, dalS das fuhrende System (im Beispiel 
das OLTP-R/3 -System) zugleich mit der Ablehnung das in 
dem Datenobjekt - wie weiter oben erlautert - enthaltene 
"Bild des vorherigen Zustandes" (Before Image) BI an das 



gefuhrte System zuruckschickt . Damit kann ein Roll Back 
durch Einspi-elen des* Original zustandes erfolgen. 

Ein Nachteil dieser Verfahrensweise besteht jedoch darin 
daG damit samtliche Anderungen des Benutzers in dem je- 
weiligen Datenobjekt uberschrieben werden. Wenn es sich 
beispielsweise um einen Auftrag mit uber hundert Posit io- 
nen handelt, der moglicherweise wegen einer vergleichs- 
weise geringf ugigen Inkonsistenz abgelehnt wurde, besteht 
das Bedurfnis, die Daten des fehlerhaften und deswegen 
nicht akzeptierten Datenobjektes dem Benutzer, von dem 
die Anderung ausgegangen war, wieder zur Verfugung zu 
stellen. Dies gesehieht mittels -dex^ I nbox*^ Deosfe Benutzer 
kann dann„die *Eintrage komfortabel anpasseni&und "erneut 
ve r f ftgba ja&machem^ 

Die ^Funkt ionndesj^PeXddng, Counter .und der Iiiboxr i s t in Fi - 
gur 17- arihand seines Bed spiels dargesteldtf Dabei symbol i- 
siert die mit LD uberschriebene Spalte den* Inhalt der lo- 
kalen Datenbank mit jeweils einem Feld, das den Status 
des Pending Counter PC anzeigt, dem Primarschlusself eld K 
und drei Datenfeldern D. 

In einem ersten Schritt wird der Inhalt des mittleren Da- 
tenfeldes geandert . Das BDoc, das die Information an das 
OLTP-R/3 -System uberbringt, enthalt nur die geanderte In- 
formation " 2 n . 

Im nachsteen*? Schritt werden zwei Dafeen*f elderapgeandert . Die 
geandert emlnfoEmat-ianen" " B 11 und "3" werden*- eben-faMs als 
BDoc ubertragen. Im vierten Schritt trifft die Bestati- 
gung der ersten Anderung und im funften Schritt die Be- 
statigung der zwei ten Anderung ein. Der Pending Counter 
PC zeigt jeweils den Bestatigungszustand an. 
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Im sechsten Schritt erfolgt eine fur das fuhrende System 
nicht akzeptable Anderung, die durch ein sternf drmiges 
Symbol gekennzeichnet ist. Diese Anderung wird abgelehnt 
als Fehlemachricht M E" , so daS im achten Schritt der Zu- 
stand vor dieser Anderung wiederhergestellt wird. Gleich- 
zeitig wird in die Inbox der (abgelehnte) geanderte Zu- 
stand gestellt, so dafi der Benutzer daran weiterarbeiten 
kann. Eine mittlerweile in dem siebten Schritt vorgenom- 
mene zulassige Anderung in dem ersten Feld wird in dem 
achten Schritt bestatigt. 

Die Erzeugung der Before -Images erfolgt unter der Kon- 
trolle der FluSsteuerung des MS -Systems mittels eines Re- 
ject-Services. Dieser pruft anhand eines im Header des 
BDocs gesetzten Flags, ob das gesamte BDoc bestatigt oder 
abgelehnt wurde. Im Falle der Ablehnung extrahiert der 
Reject -Service die Gesamt-Daten des BDocs aus der konso- 
lidierten Datenbank CD und stellt sie innerhalb des BDoc 
als Before-Images bereit. Wird das Gesamt-BDoc akzep- 
tiert, so pruft der Reject -Service dessen Teilsegmente 
auf ihren Status. Im Falle der Ablehnung eines Teilseg- 
mentes werden dessen Inhalte ebenfalls aus der konsoli- 
dierten Datenbank CD extrahiert und in den Before-Images 
bereitgestellt . 

Das fuhrende System muE im Rahmen des LSC-Verf ahrens in 
der Lage sein, eingehende Da ten zu prufen und erforderli- 
chenfalls abzulehnen. Diese Funktion ist bei Back-off ice- 
Systemen ublicherweise implementiert . Weitere auch in 
diesem Zusammenhang wichtige Funktionen wurden schon be- 
schrieben. Hierzu gehort die Datenerganzung im Falle der 
Annahme, die im Zusammenhang mit dem Data-Merge-rVerf ahren 
beschrieben wurde, und die Ubertragung des Primarschlus- 
sels des fuhrenden Systems, die ebenfalls bereits be- 
schrieben wurde . 
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5. Ausbau und Variationen des dargestellten Verbund- 
sys terns 

In dem dargestellten Beispiel wurde im wesentlichen ;der 
Datenaustausch zwischen dem Middleware -Server MS, der den 
Zentralrechnung eines CRM-Front -of f ice -Systems bildet, 
und dem OLTP-R/ 3 -System als Beispiel eines ERP-Back-of- 
fice- Systems beschrieben. 

Die beschriebenen Verf ahrensweisen land Algorithmen sind 
jedoch auch auf andere Falle anwendbar. Insbesondere kann 
das Middleware -System MS unter Verwendung der beschriebe- 
nen Ve r f ahren *mi t "unters cfai ed-M chen.. wei»t e ren, ; Da t enbanksy - 
stemen komrrruni zi eren / der en logischer Auf bau^auf <: der 
Ebene .der 'bearbeite.ten^Obij,ekte^ -Uber- 
lappungenflszea'gt^ wahr^end* ihr^e ^^ der 
programmteechnd sjshenitfRe^ . Das 

MS'- Sys t em#kann^somi*t;:Tunt er Ver^endung^de^beschr iebenen 
Verf ahrensweisen^ als Vermitt lungs system zwischen unter- 
schiedl ichen - Fremd - Da t enbanksy stemen verwende t werden . 
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Anspruche 

Verfahren zum Austausch von Daten zwischen zwei Da- 
t enbanksy s t emen A und B, wobei jedes der Datenbank- 
systeme zur eindeutigen Identif izierung gespeicherter 
Datenobjekte fur jedes Datenobjekt mittels einer Pri- 
marschlussel-Erzeugungslogik einen systemspezif ischen 
Primarschlussel (K A bzw. K B ) generiert und die Pri- 
marschlussel-Erzeugungslogiken der beiden Daten- 
banksysteme A und B voneinander unabhangig sind, 

bei welchem zur Ermoglichung der fur systemubergrei- 
fend gesharte Neuerf assungen notwendigen eindeutigen 
Identif izierbarkeit von aus einem Ur sprung s da tenbank- 
system A (OLTP-R/3) in ein Zieldatenbanksystem B 
transport ierten Datenobjekt en folgende Schritte 
durchgef uhrt we r den : 

a) Der Primarschlussel (K A ) von Datenobj ekten, die 
von dem Ursprungsdatenbanksystem A in das Zielda- 
tenbanksystem B transportiert werden soli, werden 
mittels eines Primarschlusselgenerators (KG) mit 
einer Schlussel -Mapping-Tabelle (KMT) verglichen, 
die die Primarschlussel (K A ) und (K B ) aller Da- 
tenobjekte, fur die bereits beide Primarschlussel 
(K A und K B ) generiert wurden, enthalt; 

b) wenn der Primarschlussel (K A ) in der Schlussel - 
Mapping-Tabelle (KMT) noch nicht vorhanden ist, 
wird automat isch ein Primarschlussel (Kg) des 
Zieldatenbanksystems B erzeugt, in dem Daten- 
objekt gespeichert und zusammen mit dem Primar- 
schlussel (K A ) des Ursprungsdatenbanksystems A in 
der Schlussel -Mapping-Tabelle KMT abgelegt; 
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c) wenn der Primarschlussel (K A ) des Ursprungsdaten- 
banksystems A in der Schlussel-Mapping^Tabelle 
(KM3?) gefunden wurde, wird der enfcspreehende Pri- 
marschlussel (K B ) des Zieldatenbanksystems~B in 
dern Datenobjekt gespeichert. 

Verfahren nach Anspruch 1, bei welchem der Primar- 
schlusselgenerator (KG) in dem Zieldatenbanksystem B 
integriert ist . 

Verfahren nach einem der Anspruche 1 oder 2, bei wel- 
chem der Primarschlussel (Kg, K MS ) des Zieldaten- 
banksys terns B (MS*)- nicht Bestandteil der., in der. Da- 
t enbank { OLTP - DB ) de s*4Jr sprungs da t eiibanks^s t ems -A 
(OErcP£*R/3 y , abgespeivchezyt^ 

Veasf .atoasen*:- naeh^Anspruch^S ,m bei^we>lch^m^de v r|*Pr - 
sch^usfsel*. (K|7, v K$g,)«, des*»Zi;el«dafcenbanksys terns B (MS) 
bei einem Ruckubei=tritt des Datenobjek-ts in das 
Ursp rungs datenbanksys tern A (OLTP-R/3) aus dem Daten- 
objekt abgetrennt und geparkt wird. 

Verfahren zum Updaten des Datenbestandes in einem 
zweiten Datenbanksys tern B (MS) aufgrund von Anderun- 
gen, die in einem ersten Datenbanksys tern A (OLTP-R/3) 
im dortigen Da tenbe stand durchgefiihrt wurden, wobei 

der Da tenbe stand des ersten Da tenbanksyst?enr~A ^(OLTP- 
R/3) sowohl fur das zweite Datenbanksys terns B ,(MS) 
nicht relevante Daten (D R / 3 ) als auch fur das^zweite 
Dafcenbanksysfeem A relevante Daten (D^jx) enthalt, 

die Daten in den Datenbanksystemen in Form von Daten- 
objekten bearbeitet werden, die jeweils einen sy- 
stemspezif ischen Primarschlussel (^is /K R/3^ enthal- 
ten, und 
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die Daten in dem zweiten Datenbanksys terns B (MS) mit 
beiden systemspezif ischen Primarschlusseln (K R y 3 und 
Kj^g) gespeichert werden, 

bei welchem mindestens ein Teil folgender Verfahrens- 
schritte durchgefuhrt wird: 

a) Abtrennen der fur das zweite Datenbanksys terns B 
(MS) nicht relevanten Daten D R/ , 3 aus dem Daten- 
ob j ekt ; 

b) Ubertritt des Datenobjektes von dem ersten Daten- 
banksystem A (OLTP-R/3) in das zweite Datenbank- 
sys tern B (MS) ; 

c) Erzeugen eines fur das Datenbanksys tern B (MS) 
spezifischen Schlussel (Kj^g) und Hinzufugen des 
erzeugten Schliissels (K^ s ) zu dem Datenobjekt und 

d) Einbringen des entstandenen Datenobjektes (BDoc) 
in die Abspeiche rungs routine des zweiten Daten- 
banksystems B (MS) und Abspeichern der in dem Da- 
tenobjekt enthaltenen Daten in der Datenbank (CD) 
des zweite Datenbanksys tern B (MS) . 

6. Verfahren nach Anspruch 5, bei welchem der Daten-Re- 
kord des Datenobjektes vor dem Einbringen in die Ab- 
speicherungsroutine mit Erganzungswerten (D MS ) er- 
ganzt wird, die dem Datenbestand des zweiten Daten- 
banksystems B (MS) entsprechen. 

7. Verfahren zum Updaten des Datenbestandes in einem er- 
sten Datenbanksys tern A (OLTP-R/3) aufgrund von Ande- 
rungen, die in einem zweiten Datenbanksys tern B (MS) 
im dortigen Datenbestand durchgefuhrt wurden, wobei 

der Datenbestand des zweiten Datenbanksys terns B (MS) 
sowohl fur das erste Datenbanksys tern A (OLTP-R/3) 
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nicht relevante Daten (D Mg ) als auch fur das erste 
Datenbanksystem A relevante Daten (D MIX ) enthalt, 

die Daten* in den Datenbanksystemen in Form von Daten- 
objekten bearbeitet werden, die jeweils einen sy- 
stemspezifischen Primarschlussel (K MS ,K R / 3 ) enthal- 
ten, und 

die Daten in dem ersten Datenbanksystem A (OLTP-R/3) 
nur mit dessen systemspezif ischem Primarschlussel 
(K R /3> gespeichert werden, 

bei welchem mindestens ein Teil folgender Verfahrens- 
schritte durchgefuhrt wird: 

a) Abtrennen dezv fur das erste -DaifeenbankSiy<s tern A 

(0LXP-RA3) nich^ r^^^ dem Da- 

tenobgiekt und>Parke^di*ese-^ zweiten 
Datenbanksysfeera^B I(MSt)^; 

b) Ubesferitot desj^Datenobjrektes" vc>n^dem^zweiten Da- 
tenbanksystem B (MS») in tdas erste Datenbanksystem 
A (OLXErR/J) ; 

c) Abtrennen des fur das zweite Datenbanksystem B 

(MS) systemspezif is chen Schlussels (K MS ) aus dem 
Datenobjekt und Parken dieses Schlussels (K^) in 
dem ersten Datenbanksystem A (OLTP-R/3) ; 

d) Einbringen des entstandenen Datenobjektes in die 
Abspeicherungsroutine des ersten Da tenbanksys terns 
A (OLTP-R/3) und Abspeichern der in dem*£>atenob- 
jekt enthaltenen Daten in der Datenbamk (OLTP-DB) 
des'-ersteen Dafeenbankssysfeems^A (OLTP-R'A3) . 

Verfahren nach Anspruch 7, bei welchem der Daten-Re- 
kord des Datenobjektes vor dem Einbringen in die Ab- 
speicherungsroutine mit Erganzungswerten (D D ) erganzt 
werden, die dem Datenbestand des ersten Datenbanksy- 
stems A (OLTP-R/3) entsprechen. 
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9. Verfahren nach einem der Anspruche 7 oder 8, bei wel- 
chem wenigstens ein Teil folgender weiterer Verfah- 
rensschritte stattfindet: 

e) Auslosen eines Events als Folge des Abspeicherns 
in der Datenbank (OLTP-DB) des ersten Datenbank- 
sys terns A (OLTP-R/3) ; 

f) Empfangen des Events durch eine auf das Event 
abonnierte Komponente (RSA) des zweiten Daten- 
banksys terns B (MS) ; 

g) Hinzufugen des geparkten fur das Datenbanksystem 
B (MS) spezifischen Schlussels (K^ g ) ; 

h) Entfernen von fur das erste Datenbanksystem A 
(OLTP-R/3) spezifischen Daten (Dpy 3 ) ; 

i) Ubertritt in das zweite Datenbanksystem B in Form 
eines Datenobj ektes, das die fur beide Datenbank- 
systeme relevant en Daten D^^ den fur das Daten- 
banksystem B (MS) spezifischen Schlussel (K^g) 
und den fur das Datenbanksystem A (OLTP-R/3) spe- 
zifischen Schlussel (K R / 3 ) enthalt; 

j) Hinzufugen der in dem zweiten Datenbanksystem B 
* (MS) geparkten fur das erste Datenbanksystem 
nicht relevant en Daten (D MS ) . 

10. Verfahren zur Neuerfassung oder Anderung von Daten in 
einem Verbund mehrerer Datenbanksysteme (OLTP-R/3, 
MS) , bei welchem zur Vermeidung von Datenkonf likten 
bei der gesharten Neuerfassung von Daten in einem be- 
liebigen der Datenbanksysteme des Verbundes 

fur jedes zwischen den Datenbanksystemen austausch- 
bare Datenobj ekt eines der Datenbanksysteme (OLTP- 
R/3) als fuhrendes System FS definiert wird und 
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bei jeder Neuerfassung oder Anderung in einem gefuhr- 
ten Systems GS (MS) von Daten des Datenobj ekts> die 
auch zum Datenbe stand des fuhrenden Systems FS (OLTP- 
R/3) gehdren, ein systemubergrei fender Bestatigungs- 
algorithmus durchgefuhrt wird, bei dem 

a) ein Datenobj ekt, das die Anderung beinhaltet, zu 
dem fuhrenden System FS (OLTP-R/3) transport iert 
wird, 

b) in dem fuhrenden System FS eine Ruckmeldung in 
Form einer Bestatigung oder mindestens teilweisen 
Ablehnung der Anderung erzeugt wird und 

c) ein Datenobj ekt, das die Ruckmeldung enthalt, zu 
dem gefuhrten System GS (MS) zurucktransportiert 
wird . 

11 . Verf ahren nach Anspruch 10 , bei. welchem eine Daten- 
bank : LD des gefuhrten Systems GS (MS), den Bestati- 
gungszustand eines geanderten Datenobj ektes mittels 
eines Zahlerfeldes protokolliert , dessen Zahlerstand 
mit jeder Anderung in einem dem Zahlerfeld zugeordne- 
ten Datensatz erhoht und mit jeder Ruckmeldung ver- 
mindert wird, so da£ das Zahlerfeld in dem gefuhrten 
System GS (MS) die Anzeige des Bestatigungszustandes 
und der Anzahl der Anderungen, fur die noch keine 
Ruckmeldung vorliegt, ermoglicht. 

12. Verfahren nach einem der Anspruche 10 oder 11, bei 
welchem -im Falle ^einer mindestens teilweisen Ableh- 
nung der Anderung ein Before Image des Zustandes vor 
der Datenanderung verwendet wird, um in dem gefuhrten 
System GS (MS) diesen Zustand wiederherzustellen. 
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Verfahren nach Anspruch 12, bei welchem im Falle ei- 
ner Fehlermeldung in dem gefuhrten System GS (MS) 
auch der fehlerhaft geanderte Zustand zur Korrektur 
und weiteren Bearbeitung zur Verfugung gestellt wird. 
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Zusammenf as sung 

In Unternehraen und anderen Organisationen sind umfangrei- 
che Datenbestande mit uberlappenden Dateninhalten in un- 
terschiedlichen Datenbanksystemen, deren Datenbankstruk- 
turen zueinander inkompatibel sind, gespeichert . Die Er- 
findung befafit sich mit der Integration solcher struktu- 
rell inkompatibler Datenbanksysteme, insbesondere mit dem 
Datenaustausch zwischen solchen Systemen. Es werden ver- 
schiedene Verfahren vorgeschlagen, die dem Ziel dienen, 
derartige Datenbanksysteme so miteinander zu verschmel- 
zen, dalS ein problemloser Datenaustausch in beiden Rich- 
tungen moglich ist . Insbesondere wird die Neuerf as sung 
und Anderung systemubergreif end gesharter Daten in den 
unterschiedlichen Systemen ermoglicht. 
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